.Net - DataSet... с динамическими таблицами
Как все должно быть знают, в .Net DataSet создается таким каким он описан в его схеме.
Поверх этого накладывается всякая мелочь написанная прогерами... времени на это
убивается столько, что охота все бросить... особливо, если база еще не до конца
спроектирована, а таблицы используются в нескольких датасетах...
В .Net есть утилитка xsd.exe слегка упрощающая жизнь - по предоставленной схеме
может сгенерить тот код, что предоставляет Студия при создании датасета. Схему,
в большинстве случаев, можно выгрузить какой-нибудь тулузкой... В прочем, в ситуации
с меняющейся базой это все одно достаточно неприятно...
Думаю, что избежать большинства неприятностей с меняющейся базой можно если
сделать врапер к датасету, полностью изолирующий сам датасет и предоставляющий
интерфейсы в терминах задачи(базы?).
Что-то типа такого (от балды):
База:
таблица Order
- IDs PK;
- ClientID FK;
- ItemID FK;
- Qty int;
таблица Goods
- IDs PK;
- Description string;
- Notes text;
таблица Clients
- IDs PK;
- Name string;
- Shurename string;
- DateOfBirth date;
Тогда представление может быть таким
public class TMyDB
{
...
public TOrder Order { get; }
public TGoods Goods { get; }
public TClients Clients { get; }
// какой-то обобщенный интерфейс
Load() {...}
Save() {...}
Clear() {...}
}
public class TOrder
{
public TOrderRows Rows { get; }
// и опять интерфейс
Load() {...}
Save() {...}
Clear() {...}
}
...
public TOrderRow
{
public PK IDs { get; }
public FK ClientID { get; set; }
public FK ItemID { get; set; }
public int Qty { get; set; }
}
и т.п.
При трех таблицах в базе все это можно вполне запихать в один датасет и не сильно волноваться
об последствиях. Однако при сотне-другой таблиц датасет станет слишком тяжелым. А при
частичной загрузке связанных данных - практически неуправляемым. Потому, думаю, что создавать
реальные представления таблиц нужно в динамике. Например, при первом обращении к таблице.
Все вроде выглядит не сложно.
Вопрос в том, что и как создавать. Классы, сгенеренные xsd.exe вполне неплохи, но в этом
варианте достаточно бесполезны. Так что практически весь код создания таблицы и добавления
ее в датасет отпадает. Можно написать новый генератор, но как-то лениво с этим возится.
Потому есть желание иметь аналог xsd.exe, выполняющий не генерацию кода, а создание
собственно заданной таблицы на базе XSD-схемы. Порылся в инете на предмет подобных вещей
- пока
не нашел - все идут проторенной дорожкой - схема > код > Студио и пляски с бубном.
Хотелось бы услышать мнение об самой идее и об способе реализации.
P.S. К NHibernate пока просьба не отсылать... 
P.S. К NHibernate пока просьба не отсылать...
В начале поста надо было это написать. А то я уж было начал тебя туда отсылать.
А почему собственно не отсылать?
Что-то упрощающее до уровня:
TDb db = TDb.Instance;
db.StorageInterface = new TStorageInterfaceImpl(); // замена имеющегося по умолчанию
TTableA tableA = db.TableA;
for(int i= 0; i<100; ++i)
{
TTableARow tableARow = tableA.NewRow(); // или = tableA.Rows.New(); - не решил еще
tableARow.IntegerField = i;
}
tableA.Rows[40].IntegerField = 440;
db.Save(); // вся сотня записей для этого примера и все данные что имеются (для нескольких таблиц)
db.Clear();
// работаем с двумя таблицами
TTableB tableB = db.TableB;
TTableB tableС = db.TableС;
etc...
т.е. интуитивно понятное и генерируемое без проблем.
С NHibernate у меня получается сложнее... хотя, возможно, Я потратил на него недостаточно
времени...
Потом смотрел внимательнее... в тех задачах, под которые Я нарабатываю код, есть всего
2-3 места, где выполнить работу не используя LINQ или SQL будет относительно сложно...
Так что Я решил на нем не заморачиваться и подумать об том, как сделать ту же работу, но
более легким способом... пришел в выводу, что надо определить что-то типа TFilter на базе
массива записей и отдавать его в качестве параметра. Не на много сложнее дополнительного
синтаксиса LINQ и не выпадает из парадигмы ООП...
Если они с SP1 кучу нового включают, что собственно минимум 3.6 должно называться.