Сущности и атрибуты

6yrop

Пусть есть магазины и продукты:

Замечу, что атрибутов у сущностей очень много, у одной сущности может быть 100-200 атрибутов, поэтому введены краткие названия: М001 -- процентная ставка, взимаемая с магазином, П001 -- цена продукта без комиссии магазина. На C# формула для вычисления полной цены выглядит так
DataRow row;
...
(decimal)row["П001"] * (1 + (decimal)row.GetParentRow("МагазинПродукт")["М001"]/100);
Вызывать функцию GetParentRow("МагазинПродукт") не удобно: надо смотреть схему. В тех. задании эта формула выглядит так П001*(1+М001/100). Хотелось бы, чтобы в коде формула выглядела максимально похожим образом. Для этого можно обернуть строку DataRow в свой объект Entity, и хочется, чтобы формула выглядела так
Entity entity;
...
entity["П001"] * (1 + entity["М001"]/100);
т.е. атрибут М001 должен принадлежать (виртуально) сущности типа Продукт.
Можно ли такое сделать в общем случае, опираясь только на схему?

katrin2201

возможно имеет смысл подумать об использовании ORM

6yrop

почему Microsoft нам этого не сделала, а предлагает Dataset-ы?

Dasar

Потому что Microsoft предоставляет низкоуровневый API, а не API прикладного уровня.

6yrop

какие ORM посоветуете посмотреть?

6yrop

на сколько я понял ORM предлагается вместо ADO.Net, т.е. уровень низости у них один
http://www.olero.com/OrmWeb/

katrin2201

ORM.NET почти наверно надстройка над ADO.NET.
Использование ORM.NET позволяет обойтись без использования ADO.NET в своем коде.

6yrop

ORM.NET почти наверно надстройка над ADO.NET.

под ADO.Net я имел ввиду DataSet-ы, понятно, что Connection, Command ... там используется
т.е. ORM.NET предлагается в качестве замены DataSet-ов

6yrop

посмотрел я ORM.NET, может и пригодиться, НО сгенерированные классы не Serializable, поэтому напрямую для распределенных приложений ORM.NET не подходит. Возвтрат к двух-уровневой модели?

6yrop

да, кстати, проблему, описанную в первом посте, ORM.NET не решает

katrin2201

Я ни разу не работал с ОРМ.НЕТ, но, думаю, просто не может такого быть, чтоб персистнутый класс нельзя было сделать сериалайзабельным. Уж в самым крайнем случае можно сделать еще один класс - декоратор, или любой другой подходящий паттерн заюзать.
А с твоей формулой делать так. ОРМ тул сгенерит тебе класс Продукт, в котором будет свойство Магазин. Вот и определи в классе Продукт метод типа getM001 который обратится к своему магазину и возьмет там его значение. После этого твоя формула будет выглядеть(внутри методов Продукта) как то так

getP001*(1+getM001/100)

6yrop

Я ни разу не работал с ОРМ.НЕТ, но, думаю, просто не может такого быть, чтоб персистнутый класс нельзя было сделать сериалайзабельным. Уж в самым крайнем случае можно сделать еще один класс - декоратор, или любой другой подходящий паттерн заюзать.

имхо, не так просто как может показаться на первый взгляд, и в ОРМ.НЕТ этого не сделали

А с твоей формулой делать так. ОРМ тул сгенерит тебе класс Продукт, в котором будет свойство Магазин. Вот и определи в классе Продукт метод типа getM001 который обратится к своему магазину и возьмет там его значение. После этого твоя формула будет выглядеть(внутри методов Продукта) как то так

в том то и вопрос, чтобы ничего не писать, а опираться только на схему

ava3443

возможно имеет смысл подумать об использовании ORM

Вопрос не в тему - а есть ли под .Net ORM уровня, сравнимого с Hibernate 3 ?

katrin2201

гоу на rsdn.ru _В ПОИСК_ =)

katrin2201

в том то и вопрос, чтобы ничего не писать, а опираться только на схему

Гм. Вообще, так не бывает, чтоб ничего не писать, и все работало как ты хочешь =)
Если ты все-таки хочешь еще упростить себе задачу, и твоя база данных достаточно мощная, то сделай себе CREATE VIEW где у тебя будет сджойненный продукт с магазином, и натрави на него ORM. Тогда писать не придется

6yrop

Гм. Вообще, так не бывает, чтоб ничего не писать, и все работало как ты хочешь =)

если схема представляет граф без цикла,то (наверное ) понятно как действовать -- использовать путь между сущностью и атрибутом. В принципе, можно и ограничиться этим случаем, а если из-за цикла возникает два пути, то кидать исключение (или если писать генерилку кода, то такие атрибуты не генерить).
Но вот у меня некоторые сомнения, всегда ли этот путь подразумевает человек

6yrop

по-моему, если объекты буду сериалайзебл, то получатся те же самые типизированные ДатаСеты, нет?
P.S. запросы можно и на SQL писать, то, что они заполняют по одной табличке не очень удобно, но терпимо

katrin2201

Вот уж тормоза будут у этого приложения.
Да и накодить поиск пути/атрибута - это нельзя сказать что ничего не накодить =)
По поводу ОРМа - воткни object/relation model mismatch . Оттуда сразу станет ясно, что тебе дает ОРМ сверх датасетов.

6yrop

Оттуда сразу станет ясно, что тебе дает ОРМ сверх датасетов.

и что же она дает?

6yrop

Вот уж тормоза будут у этого приложения.

, если делать генерилку кода (что я конечно делать не буду то производительность вообще не измениться. В случае поиска пути в run-time о произволительности тоже не стоит беспокоиться, поскольку схема обычно представляет не такой уж большой граф.

Да и накодить поиск пути/атрибута - это нельзя сказать что ничего не накодить =)

это не большой кусок кода, который не завязан на бизнес логику, да и вообще на конкретное приложение, его один раз написал, отладил, протестил, и радуешься жизни, используя его

katrin2201

Похоже, ты имеешь готовое решение своей проблемы, тебя полностью устраивающее =)
В чем тогда был твой вопрос?
ЗЫ Чем плохо написать один длинный SQL запрос чтобы он у тебя достал весь граф?
Мое CREATE VIEW ты проигнорировал =)

6yrop

Мое CREATE VIEW ты проигнорировал =)

ненормализованные таблички не удобны, если у тебя нет продуктов в магазине, то при обычном джойне он вообще не попадет в результат, внешнее соединение тоже не удобно