Попробуйте изменить эту строку кода:
public class Bcollection
{
List listB;
следующим образом:
public class Bcollection
{
public List listB;
Также если Вы не хотите отображать определенные элементы Ваших бизнес-объектов, установите, пожалуйста:
1) атрибут [Browsable(false)] для этих объектов.
2) статическое свойство: StiOptions.Dictionary.BusinessObjects.FieldsProcessingType = StiFieldsProcessingType.Browsable
Спасибо.
Построение отчета на базе Объектов
- compositum
- Сообщения: 252
- Зарегистрирован: 15 янв 2008, 15:12
- Откуда: Санкт-Петербург
Построение отчета на базе Объектов
Да, вы правы - в этом случае класс В появляется в данных, однако предоставлять доступ к List listB не хотелось бы, т.к. в этом случае я теряю контроль над тем, как работают с с объектами, хранящимися в нем. В реальном Bcollection классе я реализовал индексаторы, и интерфейсы: IEnumerator() и IEnumerable(), что позволяет мне работать с данным классом, как с полноценным классом-коллекцией. В нем так же реализованы другие нужные мне интерфейсы (помимо указанных), через реализацию которых производятся различные расчеты и операции с содержимым List listB, который скрыт от посторонних глаз. Если я открою доступ к нему - появится возможность обратиться к содержимому в обход созданного мною интерфейса, что, как вы понимаете, сведет на нет всю проделанную мною работу...Edward писал(а):Попробуйте изменить эту строку кода:
public class Bcollection
{
List listB;
следующим образом:
public class Bcollection
{
public List listB;
Также если Вы не хотите отображать определенные элементы Ваших бизнес-объектов, установите, пожалуйста:
1) атрибут [Browsable(false)] для этих объектов.
2) статическое свойство: StiOptions.Dictionary.BusinessObjects.FieldsProcessingType = StiFieldsProcessingType.Browsable
Спасибо.
Как вариант - я реализую в своем классе метод, возвращющий объект DataSet, который так же смогу передавать в качестве источника данных отчету стимула. Это своего рода перестраховка на случай, если решить (как я уже чувствую) задачу с учетом нужных мне требований не удастся.
Вопрос: есть ли способ решения задачи без изменения области видимости List listB?
Построение отчета на базе Объектов
Да, наверное вариант с DataSet будет наиболее простым и надежным способом передачи данных в отчет в Вашем случае.compositum писал(а): Да, вы правы - в этом случае класс В появляется в данных, однако предоставлять доступ к List listB не хотелось бы, т.к. в этом случае я теряю контроль над тем, как работают с с объектами, хранящимися в нем. В реальном Bcollection классе я реализовал индексаторы, и интерфейсы: IEnumerator() и IEnumerable(), что позволяет мне работать с данным классом, как с полноценным классом-коллекцией. В нем так же реализованы другие нужные мне интерфейсы (помимо указанных), через реализацию которых производятся различные расчеты и операции с содержимым List listB, который скрыт от посторонних глаз. Если я открою доступ к нему - появится возможность обратиться к содержимому в обход созданного мною интерфейса, что, как вы понимаете, сведет на нет всю проделанную мною работу...
Как вариант - я реализую в своем классе метод, возвращющий объект DataSet, который так же смогу передавать в качестве источника данных отчету стимула. Это своего рода перестраховка на случай, если решить (как я уже чувствую) задачу с учетом нужных мне требований не удастся.
Вопрос: есть ли способ решения задачи без изменения области видимости List listB?
Вычислияемую колонку или свойство создать не получиться, если будет возвращаться строковое значение (к примеру B.propB1) или какой-либо добавленный Вами в класс метод. Даже если и удасться реализовать такую 'обертку' для метода, то значение будет одинаковым для всей коллекции.
Я вижу лишь одну альтернативу возвращаемому DataSet, и не уверен, что она лучше. Это свойство-коллекция. Значения из этой коллекции будут возвращаться динамически для всего списка Bcollection, при каждом обращеннии к этому свойству через get секцию Вашего свойства.
Ваш вариант с DataSet все-же более предпочтительный, универсальный и наглядный.
Спасибо.