Здравствуйте, gloomy rocker, Вы писали:
GR>Мне например в типизирванном DataSet-е не хватает возможности добавить в какой-нить MyObjectRow собственный метод, реализующий бизнес-логику. Сейчас приходится решать это путем агрегации(наследоваться — себе дороже выйдет). Вот если бы решить эту проблему путем добавления абстрактных методов во время дизайна, а потом реализовать их.
У типизированных датасетов 2 проблемы: non extendable & not reusable. В основном проблема не в самих датасетах, а в генераторе кода.
GR>Но мне кажется, что в Whidby это(или что-то подобное) уже сделано.
Там есть ObjectSpace.
GR>То есть если уж делать велосипед, то он должен быть легче DataSet-а, иначе смысла особого нет. А если реализовать все, что использую в DataSet-e, то получится еще один монстр.
GR>В общем надо определиться с областью применения.
Это правильно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
W>>2. Это больше риторическая проблема.
IT>В юнит тестах я делаю примерно так же.
W>>Как насчет что-нибудь похожее реализовать у себя?
IT>Как это сделать, чтобы было не коряво
Конечно, не хочется заставлять всех писать на "универсальном" SQL с разметкой параметров. Может, имеет смысл сделать для этого специальный режим? Т.е. если он включен, то делать замену, если нет, ну... ничего страшного
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, mihailik, Вы писали:
M>>А разве System.DataTable.Select генерирует на лету SQL?
IT>Вот ты о чём. Для этого можно ввести тип BizEntityList и делать это в нём. Проще всего на делегатах.
И еще добавить в BizEntityList метод Merge(BizEntityList list) или Merge(BizEntity[] list).
IT>Вот ты о чём. Для этого можно ввести тип BizEntityList и делать это в нём. Проще всего на делегатах.
Оптимально было бы через Reflection.Emit для каждого типа элемента генерировать "проходчик", чтобы он не лез по позднему связыванию читать свойства, а по раннему связыванию обращался и фильтровал.
Правда, такую оптимизацию как индексы тут трудно будет прикрутить.
Конечно, слишком много труда нужно убить на этот SQL-прожект.
Здравствуйте, mihailik, Вы писали:
IT>>Вот ты о чём. Для этого можно ввести тип BizEntityList и делать это в нём. Проще всего на делегатах.
M>Оптимально было бы через Reflection.Emit для каждого типа элемента генерировать "проходчик", чтобы он не лез по позднему связыванию читать свойства, а по раннему связыванию обращался и фильтровал.
Я же тебе говорю — делегаты. И ничего на эмите генерировать не надо.
M>Правда, такую оптимизацию как индексы тут трудно будет прикрутить.
Если не ошибаюсь, то Select из DataTable умеет индексировать таблицу, но к сожалению, как раз для селекта это делается каждый раз. Т.е. каждый раз будет по новой строиться индекс.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, mihailik, Вы писали:
M>Кто знает, не будет ли следующая версия ADO.NET построена на генериках?
В ADO.NET из беты 1.2 никаких генериков нет.
M>В особенности, это может прибавить скорости, если данные по строкам каким-то хитрым способам хранить в структурах. Сейчас-то они боксируются вроде бы.
Данные и так с самого начала хранятся по столбцам в массивах простых типов. Боксинг идет при передаче их в и из DataTable, там шаблонный DataRow.this был бы интересен, но пока что-то движения в эту сторону не видно.
M>>Оптимально было бы через Reflection.Emit для каждого типа элемента генерировать "проходчик", чтобы он не лез по позднему связыванию читать свойства, а по раннему связыванию обращался и фильтровал.
IT>Я же тебе говорю — делегаты. И ничего на эмите генерировать не надо.
На делегатах удобно только с новой версией .NET будет, когда неименованые делегаты будут.
M>>Правда, такую оптимизацию как индексы тут трудно будет прикрутить.
IT>Если не ошибаюсь, то Select из DataTable умеет индексировать таблицу, но к сожалению, как раз для селекта это делается каждый раз. Т.е. каждый раз будет по новой строиться индекс.
Я слышал, что индекс строится в DataView, а не в DataTable.Select.
_>Данные и так с самого начала хранятся по столбцам в массивах простых типов.
Данные хранятся по столбцам?
Очен интерестно. Как-то из самой иерархии классов само собой "следовало", что данные хранятся в DataRow. Кто бы мог подумать!
И что, для NULL отдельный массив заведён на каждый столбец? Определённо нужно это изучить Спасибо за наводку.
Здравствуйте, mihailik, Вы писали:
IT>>Если не ошибаюсь, то Select из DataTable умеет индексировать таблицу, но к сожалению, как раз для селекта это делается каждый раз. Т.е. каждый раз будет по новой строиться индекс.
M>Я слышал, что индекс строится в DataView, а не в DataTable.Select.
Там одни и тот же механизм используется в обоих случаях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, mihailik, Вы писали:
M>Данные хранятся по столбцам? M>Очен интерестно. Как-то из самой иерархии классов само собой "следовало", что данные хранятся в DataRow. Кто бы мог подумать!
В DataColumn есть указатель на DataStorage, а у того — куча потомков для каждого типа.
M>И что, для NULL отдельный массив заведён на каждый столбец?
Да, битовая карта. Причем пытаются сэкономить скорость и лезут в нее не сразу, а только если в первом массиве ноль
А вот в mono все очень наивно — три массива объектов в DataRow.
Здравствуйте, IT, Вы писали:
M>>И что, для NULL отдельный массив заведён на каждый столбец? Определённо нужно это изучить Спасибо за наводку. IT>В качестве NULL используется DBNull.Value.
Он не влезет в int[]. В DataStorage есть BitArray dbNullBits.
Здравствуйте, mihailik, Вы писали:
IT>>Вот ты о чём. Для этого можно ввести тип BizEntityList и делать это в нём. Проще всего на делегатах.
M>Оптимально было бы через Reflection.Emit для каждого типа элемента генерировать "проходчик", чтобы он не лез по позднему связыванию читать свойства, а по раннему связыванию обращался и фильтровал.
А вместо изобретения велосипеда XPathNavigator не устроит?
Здравствуйте, gloomy rocker, Вы писали:
GR>Может обсудим в свободное от безделья время?
Собственно для дизайнера большой системы я примерно так как ты описал и сделал. Только плюс к тому поддержка WinForms Binding, редактирования элементов в PropertyGrid, реализация IXPathNavigable ну и еще кое что по мелочи.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gloomy rocker, Вы писали:
GR>>Может обсудим в свободное от безделья время?
AVK>Собственно для дизайнера большой системы я примерно так как ты описал и сделал. Только плюс к тому поддержка WinForms Binding, редактирования элементов в PropertyGrid, реализация IXPathNavigable ну и еще кое что по мелочи.
Если нам не помогут, то мы тоже никого не пощадим.
А потрогать это можно?