Система бизнес-аналитики Stimulsoft | Форум

Попробуйте изменить эту строку кода:

public class Bcollection
{
List listB;

следующим образом:

public class Bcollection
{
public List listB;

Также если Вы не хотите отображать определенные элементы Ваших бизнес-объектов, установите, пожалуйста:
1) атрибут [Browsable(false)] для этих объектов.
2) статическое свойство: StiOptions.Dictionary.BusinessObjects.FieldsProcessingType = StiFieldsProcessingType.Browsable


Спасибо.

Edward писал(а):Попробуйте изменить эту строку кода:

public class Bcollection
{
List listB;

следующим образом:

public class Bcollection
{
public List listB;

Также если Вы не хотите отображать определенные элементы Ваших бизнес-объектов, установите, пожалуйста:
1) атрибут [Browsable(false)] для этих объектов.
2) статическое свойство: StiOptions.Dictionary.BusinessObjects.FieldsProcessingType = StiFieldsProcessingType.Browsable


Спасибо.

Да, вы правы - в этом случае класс В появляется в данных, однако предоставлять доступ к List listB не хотелось бы, т.к. в этом случае я теряю контроль над тем, как работают с с объектами, хранящимися в нем. В реальном Bcollection классе я реализовал индексаторы, и интерфейсы: IEnumerator() и IEnumerable(), что позволяет мне работать с данным классом, как с полноценным классом-коллекцией. В нем так же реализованы другие нужные мне интерфейсы (помимо указанных), через реализацию которых производятся различные расчеты и операции с содержимым List listB, который скрыт от посторонних глаз. Если я открою доступ к нему - появится возможность обратиться к содержимому в обход созданного мною интерфейса, что, как вы понимаете, сведет на нет всю проделанную мною работу...

Как вариант - я реализую в своем классе метод, возвращющий объект DataSet, который так же смогу передавать в качестве источника данных отчету стимула. Это своего рода перестраховка на случай, если решить (как я уже чувствую) задачу с учетом нужных мне требований не удастся.

Вопрос: есть ли способ решения задачи без изменения области видимости List listB?

compositum писал(а): Да, вы правы - в этом случае класс В появляется в данных, однако предоставлять доступ к List listB не хотелось бы, т.к. в этом случае я теряю контроль над тем, как работают с с объектами, хранящимися в нем. В реальном Bcollection классе я реализовал индексаторы, и интерфейсы: IEnumerator() и IEnumerable(), что позволяет мне работать с данным классом, как с полноценным классом-коллекцией. В нем так же реализованы другие нужные мне интерфейсы (помимо указанных), через реализацию которых производятся различные расчеты и операции с содержимым List listB, который скрыт от посторонних глаз. Если я открою доступ к нему - появится возможность обратиться к содержимому в обход созданного мною интерфейса, что, как вы понимаете, сведет на нет всю проделанную мною работу...

Как вариант - я реализую в своем классе метод, возвращющий объект DataSet, который так же смогу передавать в качестве источника данных отчету стимула. Это своего рода перестраховка на случай, если решить (как я уже чувствую) задачу с учетом нужных мне требований не удастся.

Вопрос: есть ли способ решения задачи без изменения области видимости List listB?

Да, наверное вариант с DataSet будет наиболее простым и надежным способом передачи данных в отчет в Вашем случае.
Вычислияемую колонку или свойство создать не получиться, если будет возвращаться строковое значение (к примеру B.propB1) или какой-либо добавленный Вами в класс метод. Даже если и удасться реализовать такую 'обертку' для метода, то значение будет одинаковым для всей коллекции.

Я вижу лишь одну альтернативу возвращаемому DataSet, и не уверен, что она лучше. Это свойство-коллекция. Значения из этой коллекции будут возвращаться динамически для всего списка Bcollection, при каждом обращеннии к этому свойству через get секцию Вашего свойства.

Ваш вариант с DataSet все-же более предпочтительный, универсальный и наглядный.

Спасибо.