Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bober_maniac, Вы писали:

_>>Здравствуйте, Аноним, Вы писали:

А>>>Если выбирать между ObservableCollection<Dictionary<string,object>> и System.Reflection.Emit, то что выбрать?

А>>>В Emit-е в етот ихний «ассемблер» надо вникать, а зато O.C.<Dict<>> кмк кучу всего надо учесть, что, потенциально, таит тонны граблей.

А>>>Склоняюсь к emit-у, но До этого склонялся к DataTable и вона чо вышло. Кто знает оба подхода (ObCo и Emit) не могли б Вы сделать для меня обоснованный выбор?

_>>ObservableCollection<IDictionary<string, object>> с собственной реализацией IDictionary. Тогда никаких граблей, определяете только то, что вам нужно.

А>Грабли как раз в том что я не знаю заранее что «оно само сделаит» из того что мне нужно, а что определять надо. Т.е. я думаю что оно и так должно быть (само собой), а его вдруг не будет (потому что не определено).

Именно поэтому IDictionary, а не Dictionary.

Здравствуйте, bober_maniac, Вы писали:

А>>Грабли как раз в том что я не знаю заранее что «оно само сделаит» из того что мне нужно, а что определять надо. Т.е. я думаю что оно и так должно быть (само собой), а его вдруг не будет (потому что не определено).

_>Именно поэтому IDictionary, а не Dictionary.

эээ.. Интеррресно интеррресно.. Т.е. реализую этот ифейс и всё — можно будет про эту деталь проекта забыть навсегда и пользоваться направо и налево ничего не правя в коде?
Мне надо чтоб работало и не парило моск, потому что задача у меня другая — ну там прорва бизнес-логики и всякие такие мелочи прорабатывать некогда.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bober_maniac, Вы писали:

А>>>Грабли как раз в том что я не знаю заранее что «оно само сделаит» из того что мне нужно, а что определять надо. Т.е. я думаю что оно и так должно быть (само собой), а его вдруг не будет (потому что не определено).

_>>Именно поэтому IDictionary, а не Dictionary.

А>эээ.. Интеррресно интеррресно.. Т.е. реализую этот ифейс и всё — можно будет про эту деталь проекта забыть навсегда и пользоваться направо и налево ничего не правя в коде?
А>Мне надо чтоб работало и не парило моск, потому что задача у меня другая — ну там прорва бизнес-логики и всякие такие мелочи прорабатывать некогда.

Вы реализуете слой конверсии из ваших объектов с кучей полей в некий MyDictionary : IDictionary<string, object> и радуетесь жизни. Те методы IDictionary, которые вам не нужны, просто не реализуете.

А>В DbDataReader:

А>

А>DbCommand.ExecuteReader();
А>

Это со стороны сервера, а на клиент-то вы в каком виде собираетесь отдавать? Советую сначала об этом подумать, а потом уже про датагрид

Здравствуйте, bober_maniac, Вы писали:

_>Вы реализуете слой конверсии из ваших объектов с кучей полей в некий MyDictionary : IDictionary<string, object> и радуетесь жизни. Те методы IDictionary, которые вам не нужны, просто не реализуете.

Можно пример?

Исходные данные: Есть поток данных вида

{
1. Имя поля
2. Тип
3. Значение
} повторить 1 тире N раз

. Этот поток образует прямоугольную таблицу.

Здравствуйте, notacat, Вы писали:

А>>В DbDataReader:

А>>

А>>DbCommand.ExecuteReader();
А>>

N>Это со стороны сервера, а на клиент-то вы в каком виде собираетесь отдавать? Советую сначала об этом подумать, а потом уже про датагрид

В соседней ветке -- "DataTable vs Самопальный что-то там" -- это описано возможно более подробно.

Есть два рабочих проверенных варианта: 1. Передача DataSet/DataTable средствами WCF и 2. Преобразование DataTable/DataSet в свой тип-коллекцию и передача опять-таки средствами WCF (тут на самом деле я из DbDataReader читаю и строю этот тип-коллекцию минуя DataT/DataS)

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bober_maniac, Вы писали:

_>>Вы реализуете слой конверсии из ваших объектов с кучей полей в некий MyDictionary : IDictionary<string, object> и радуетесь жизни. Те методы IDictionary, которые вам не нужны, просто не реализуете.

А>Можно пример?

А>Исходные данные: Есть поток данных вида

А>{
А>1. Имя поля
А>2. Тип
А>3. Значение
А>} повторить 1 тире N раз

А>. Этот поток образует прямоугольную таблицу.\

PS. я нарыл в инете пример, в каком-то блоге, копипаст, Рун. Открывается табличка с другим количеством колонок, без заголовков (или с заголовками которые в моем коде не упоминались), с пустыми ячейками. Вот.

А>Есть два рабочих проверенных варианта: 1. Передача DataSet/DataTable средствами WCF и 2. Преобразование DataTable/DataSet в свой тип-коллекцию и передача опять-таки средствами WCF (тут на самом деле я из DbDataReader читаю и строю этот тип-коллекцию минуя DataT/DataS)
Разбирать сериализованные DataSet/DataTable на клиенте — это для вас будут лишние сложности. Лучше уж тогда свои объекты и коллекции.

зыЖ это я говорю как человек, который этих устриц ел

Здравствуйте, notacat, Вы писали:

А>>Есть два рабочих проверенных варианта: 1. Передача DataSet/DataTable средствами WCF и 2. Преобразование DataTable/DataSet в свой тип-коллекцию и передача опять-таки средствами WCF (тут на самом деле я из DbDataReader читаю и строю этот тип-коллекцию минуя DataT/DataS)
N>Разбирать сериализованные DataSet/DataTable на клиенте — это для вас будут лишние сложности. Лучше уж тогда свои объекты и коллекции.

Это воще не проблема.. т.к. Silverlight (а мне надо прикрутить именно к нему) просто не умеет DataTable/DataSet ваобще

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, notacat, Вы писали:

N>>Если совсем все динамическое, то можно тип в рантайме генерировать через Reflection.Emit.

А>Спс, я попробую Emit — это интересно. Там какие-нибудь грабли есть, например: безумно медленно или конфликт с настройками безопасности?

Готово Копипастой с MSDN и нембольшим проектированием.

Такой вопрос: созданные таким образом типы как-нибудь удалять надо/можно? Или оне автоматически уходят в небытие (правда не пойму как думатель узнает что Тип пора кокнуть)?

А>Это воще не проблема.. т.к. Silverlight (а мне надо прикрутить именно к нему) просто не умеет DataTable/DataSet ваобще
У вас какая-то путаница. Сильверлайт же не умеет DataReader, но вы про него писали зачем-то. Вы уж определитесь, я же вас спросила как вы будете отдавать данные на клиент, и это вы опять про датасет написали. Перечитайте ветку повыше.
Сильверлайт умеет xml, и этого в принципе достаточно, чтобы на клиенте раскрутить даже датасет. Мы это у себя делаем.
Но если у вас нет готовой реализации для сильверлайта, то лучше про этот вариант не думать, а сразу заняться своими коллекциями.

Здравствуйте, notacat, Вы писали:

А>>Это воще не проблема.. т.к. Silverlight (а мне надо прикрутить именно к нему) просто не умеет DataTable/DataSet ваобще
N>У вас какая-то путаница. Сильверлайт же не умеет DataReader, но вы про него писали зачем-то. Вы уж определитесь, я же вас спросила как вы будете отдавать данные на клиент, и это вы опять про датасет написали. Перечитайте ветку повыше.
N>Сильверлайт умеет xml, и этого в принципе достаточно, чтобы на клиенте раскрутить даже датасет. Мы это у себя делаем.
N>Но если у вас нет готовой реализации для сильверлайта, то лучше про этот вариант не думать, а сразу заняться своими коллекциями.

Да, эт верно. (я допускаю что со стороны это выглядит Путаницей ещо той).

Просто тестил я поначалу в консоли на полном фреймворке, и у меня был выбор: DataTable vs Коллекции. С DataTable всё на порядок проще. Потом когда стал детализировать (тестировать на SL), то ГРРРРР узнал что с DataTable придётся завязать.

У меня трёхзвёнка. Среднее звено читает DbDataReader — раньше в DataTable, а теперь в коллекцию — которые отправляет клиенту WCF-ом.

Вот, щас клиент получает коллекции, дальше я создаю подходящий тип, по Вашей подсказке, и сую в DataGrid, который для моего типа сам столбцы — «гадский папа» — не строит. Ща биндинги изучаю штоб сказку сделать былью.