Разрабатываю систему, состоящую из пары-тройки Web Application. Ядра ввиде Web-сервиса, и еще пары Web-сервисов. Долго мучался, и пришел к следующей архитектуре каждого приложения.

1. Data Access Layer
2. Buisness Logic Layer
3. Buisness Entities
4. UI (Web)

Но до сих пор не могу решить, что лучше использовать в качестке Buisness Entities, толи типизированные DataSet, генерируемые студией + генерируемые SqlDataAdapter, толи свои классы, поражденные от DataSet + свои хранимые процедуры.

Собственно инетерсно было бы узнать, как такие приложения разрабатывает народ. Поделитесь опытом плиз.

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

S>Но до сих пор не могу решить, что лучше использовать в качестке Buisness Entities, толи типизированные DataSet, генерируемые студией + генерируемые SqlDataAdapter, толи свои классы, поражденные от DataSet + свои хранимые процедуры.

S>Собственно инетерсно было бы узнать, как такие приложения разрабатывает народ. Поделитесь опытом плиз.

Самым неправильным решением было бы использование только датасетов или только бизнес объектов. И то и другое имеет свои достоинства и преимущества, соответственно и применять их нужно там где это целесообразно.

Достоинства датасетов определяются тем, что это фактически маленькая база данных со всеми вытекающими последствиями:

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

Недостатков к сожалению тоже хватает, причём многие из них являются обратной стороной медали достоинств:

— невозможность расширения датасетов своей функциональностью. Иногда хотелось бы добавить пару вспомогательных методов в row или table, но так как они глубоко упрятаны в датасет, то остаётся только курить бамбук вместе с ООП в лице инкапсуляции.
— отсутвие поддержки перечислителей, соответственно абстракция от структуры данных тоже идёт лесом. Использование захаркоженных значений расползается по системе, в результате чего их потом приходится ловить и давить как тараканов. Весьма большой минус.
— избыточная сериализация (в любой датасет всегда включается его схема).
— отсутсвие бинарной сериализации, что может увеличить трафик в разы.
— слабое повторное использование сущностей и как следствие тотальное дублирование. Можно конечно сделать xsd шаблоны и прикрутить import, но на этом как правило речь о визуальных средствах разработки заканчивается, рукова закатываются по самые уши и поехали выпиливать xsd схемы в рукопашную.

Бизнес объекты как правило лишены перечисленных недостатков, но очень часто и достоинств Большинство вещей приходится делать ручками, в частности больше всего напрягает вычитывание записей из рекордсета и маппинг. Если решить эти проблемы, то всё совсем не так уж плохо С другой стороны бизнес объекты несравненно гибче, их возможности фактически ограничены только высотой полёта твоей фантазии.

Из всего выше сказанного можно сделать следующий вывод — однозначного ответа нет

Я предпочитаю датасетам бизнес объекты, т.к. датасеты хороши либо в совсем примитивных случаях (быстро мышкой накидал), либо в клинически сложных, когда большая часть логики выносится на клиента и он там выпендривается с датасетами как хочет, а сервер потом получает только результат. В остальных 95% случаев бизнес объекты рулят и доставляют наименьшее число хлопот.

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

IT>Я предпочитаю датасетам бизнес объекты, т.к. датасеты хороши либо в совсем примитивных случаях (быстро мышкой накидал), либо в клинически сложных, когда большая часть логики выносится на клиента и он там выпендривается с датасетами как хочет, а сервер потом получает только результат. В остальных 95% случаев бизнес объекты рулят и доставляют наименьшее число хлопот.


аналогично, к тому же использование тяжеловесных Датасетов в Веб приложении часто совсем не оправданно.
не смысла грузить Мини базу данных для отображения например списка сотрудников.

у себя я использую примерно следующий вариант:

есть класс Бизнес сущности

public Class User
{
   public string Name{get{...}set{...}}
   //....
}

для него пишется класс БД:

public class CUserDB
{
    public static void Create(CUser p_user);
    public static void CreateRelation(CUser p_user,CRole p_role);
    public static void DeleteRelation(CUser p_user,CRole p_role);
    public static void Delete(CUser p_user);
    public static void Update(CUser p_user);
    public static CUser Load(string p_sUserName);
    public static CUser Load(int p_iUserID);
    public static CUserCollection GetList();
    public static CUserCollection GetList(CRole p_role);
    public static SQLDataReader GetListReader();
    protected static CUser GetObjectFromReader(SqlDataReader p_reader);
}

все операции с базой выполняются через этот класс
классы примитивные и пишутся за 15 минут.

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

IT>Бизнес объекты как правило лишены перечисленных недостатков, но очень часто и достоинств Большинство вещей приходится делать ручками, в частности больше всего напрягает вычитывание записей из рекордсета и маппинг.

можно использовать готовый OR-mapping tool.

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

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

IT>>Бизнес объекты как правило лишены перечисленных недостатков, но очень часто и достоинств Большинство вещей приходится делать ручками, в частности больше всего напрягает вычитывание записей из рекордсета и маппинг.

PZT>можно использовать готовый OR-mapping tool.

А какие готовые OR-mapping tools в природе существуют ?
Дайте ,плиз, линки кто чем пользовался.

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

IT>Самым неправильным решением было использование только датасетов или только бизнес объектов. И то и другое имеет свои достоинства и преимущества, соответственно и применять их нужно там где это целесообразно.

Согласен... как еще один вариант, при использовании Remoting'а очень медленно вычитываются данные с сервера на клиент и обратно....
самый простой выход тут — в таком конкретном случае, для UI пересылать DataTable (например)...

IT>Бизнес объекты как правило лишены перечисленных недостатков, но очень часто и достоинств Большинство вещей приходится делать ручками, в частности больше всего напрягает вычитывание записей из рекордсета и маппинг. Если решить эти проблемы, то всё совсем не так уж плохо С другой стороны бизнес объекты несравненно гибче, их возможности фактически ограничены только высотой полёта твоей фантазии.

Не твоей, а заказчика... если он только поймет, чего ты делаешь И в любом случае, трехзвенка рулит...

IT>Из всего выше сказанного можно сделать следующий вывод — однозначного ответа нет

IT>Я предпочитаю датасетам бизнес объекты, т.к. датасеты хороши либо в совсем примитивных случаях (быстро мышкой накидал), либо в клинически сложных, когда большая часть логики выносится на клиента и он там выпендривается с датасетами как хочет, а сервер потом получает только результат. В остальных 95% случаев бизнес объекты рулят и доставляют наименьшее число хлопот.

Датасеты себя исчерпывают в тот самый момент, когда надо что-то посложнее списка сотрудников выдать на экран...
конечно, схемы чуть-чуть улучшают ситуацию, но только чуть

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

H_D>Согласен... как еще один вариант, при использовании Remoting'а очень медленно вычитываются данные с сервера на клиент и обратно....
H_D>самый простой выход тут — в таком конкретном случае, для UI пересылать DataTable (например)...

DataTable отдельно сам по себе не сериализуется, его можно передать только вместе с датасетом.

H_D>Датасеты себя исчерпывают в тот самый момент, когда надо что-то посложнее списка сотрудников выдать на экран...
H_D>конечно, схемы чуть-чуть улучшают ситуацию, но только чуть

Ну как бы не совсем. Иногда нужно бывает откатить изменения, такая функциональность в датасетах есть. Правда тоже через одно отверстие. Иногда удобно отослать на сервер все изменения, проведённые над датасетом. Но в целом на больших задачах, получается что дешевле с датасетами не связываться.

А>Дайте ,плиз, линки кто чем пользовался.
Что видел и пробывал:
1.Mongoose Objectz.NET пользую сейчас, есть пара особо зверских багов, но терпимо. Есть free лицензия.
2.Thona Consulting Object Broker. Особо не смотрел, сразу отпугнула архитектура(бизнес-объекты наследуются от ContextBoundObject). Есть free лицензия.
3.OJB.NET — порт явавского OJB. Выглядит многообещающе, уже даже работает, но статус что-то вроде альфы.
4.MS ObjectSpaces — когда был, теперь уже нет, обещают в составе .NET 2.0 (если вместе с Business Framework — это будет круто)
5.NHibernate — порт с явы, вроде заглох.
Это все честные OR-Mapping tools. Есть еще куча кодогенераторов типа Deklarit, ORM и т.д.

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

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

H_D>>Согласен... как еще один вариант, при использовании Remoting'а очень медленно вычитываются данные с сервера на клиент и обратно....
H_D>>самый простой выход тут — в таком конкретном случае, для UI пересылать DataTable (например)...

IT>DataTable отдельно сам по себе не сериализуется, его можно передать только вместе с датасетом.
Странно... у меня вот такое свойство:

        public DataTable AllData
        {
            get 
            {
                DataTable retval = new DataTable();
                for (int i = 0; i < CollectionClass.PropertyCount; i++)
                {
                    DataColumn col = new DataColumn(...);
                    retval.Columns.Add(col);
                }
                foreach ( ... )
                {
                    DataRow row = retval.NewRow();
                    try
                    {
                        foreach ( DataColumn col in retval.Columns )
                        {
                            string colName = col.ColumnName;
                            object vle = obj[colName];
                            if ( vle == null )
                                row[colName] = "";
                            else if ( prop.PropertyClass != null )
                                row[colName] = vle.ToString();
                            else
                                row[colName] = vle;
                        }
                    }
                    catch
                    {
                    }
                    retval.Rows.Add(row);
                }
                foreach ( DataColumn col in retval.Columns )
                    col.ExtendedProperties["Property"] = null;
                return retval;            
            }
        }

нормально через Remoting вызывается... причем отрабатывает на сервере, а на клиент тока результат...
DataRow — не сериализуется, факт, а вот DataTable — вполне нормально...

IT>Ну как бы не совсем. Иногда нужно бывает откатить изменения, такая функциональность в датасетах есть. Правда тоже через одно отверстие. Иногда удобно отослать на сервер все изменения, проведённые над датасетом. Но в целом на больших задачах, получается что дешевле с датасетами не связываться.
в моей системе можно только дернуть коллекцию (через вышеприведенное свойство и его аналог, возвращающий DataSet) чтобы получить данные в виде DataSet, а вот все изменения делаются через Remoting и никак иначе... никаких передач DataSet'ов с клиента на сервер... разве что сделать у бизнес объекта свойство типа DataTable/DataSet.
Причина же для появления такого метода чтения данных — remoting очень медленно выполняется, особенно при использовании OwnerData/CustomDraw ListView ( aka TreeGrid2 )...
когда нужно отрисовать 20 объектов по 10 свойств у каждого — это занимает около 30 секунд при дерганьи каждого значения через remoting... а так — за какие-то мгновенья все отрабатывает

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

IT>>DataTable отдельно сам по себе не сериализуется, его можно передать только вместе с датасетом.
H_D>Странно... у меня вот такое свойство:
[skip]
H_D>нормально через Remoting вызывается... причем отрабатывает на сервере, а на клиент тока результат...
H_D>DataRow — не сериализуется, факт, а вот DataTable — вполне нормально...

Значит я не прав

H_D>в моей системе можно только дернуть коллекцию (через вышеприведенное свойство и его аналог, возвращающий DataSet) чтобы получить данные в виде DataSet, а вот все изменения делаются через Remoting и никак иначе... никаких передач DataSet'ов с клиента на сервер... разве что сделать у бизнес объекта свойство типа DataTable/DataSet.

У датасета можно запросить изменения через GetChanges и послать их серверу. Очень быстро и удобно, так что отмахиваться от них не надо.

H_D>Причина же для появления такого метода чтения данных — remoting очень медленно выполняется, особенно при использовании OwnerData/CustomDraw ListView ( aka TreeGrid2 )...
H_D>когда нужно отрисовать 20 объектов по 10 свойств у каждого — это занимает около 30 секунд при дерганьи каждого значения через remoting... а так — за какие-то мгновенья все отрабатывает

Т.е.? Ты за каждым свойством на сервер что-ли ходишь?

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

IT>У датасета можно запросить изменения через GetChanges и послать их серверу. Очень быстро и удобно, так что отмахиваться от них не надо.
Мне оно не нужно, увы.. мне лишнее кэширование не нужно... его в сервере хватает... а так — будет полная #$%%@$%@#%@!... и так мучаюсь... и с содроганием предвкушаю переделку... вернее — доделку под многопользовательский режим... как только транзакция закончилась — надо бы всех оповестить, чтобы данные перечитали... а это — жуткая вешь...
Представь себе — у каждого клиента по 50 Датасетов... а мне надо обновления клиентам разослать... попа, однако....

IT>Т.е.? Ты за каждым свойством на сервер что-ли ходишь?
теперь — нет для того и родил методы, которые DataRow/DataSet возвращают...
щаз вот еще и Кодогенерацию буду писать... но сперва — напишу статью про то, как это вссе устроено... или несколько статей...
а потом — сломаю все нафиг...
Кстати, у тебя немного времени есть? а то я тебе закинул бы того монстрика, которого наваял, чтобы ты его посмотрел

Здравствуйте, IT, Вы писали:
Дело в том, что я стою сейчас перед таким же выбором, только цели у меня учебные. Можно сказать, что собираюсь "стрелять по воробьям из пушки".

IT>Я предпочитаю датасетам бизнес объекты, т.к. датасеты хороши либо в совсем примитивных случаях (быстро мышкой накидал), либо в клинически сложных, когда большая часть логики выносится на клиента и он там выпендривается с датасетами как хочет, а сервер потом получает только результат. В остальных 95% случаев бизнес объекты рулят и доставляют наименьшее число хлопот.

Посколько Вы уже отвечали на подобный вопрос хочется уточнить, изменилось ли Ваше мнение по поводу Typed Dataset в связи с выходом VS 2005 и изменеиями в .Net 2.0(partirion class, TableAdapter и т.д).

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

IT>- невозможность расширения датасетов своей функциональностью. Иногда хотелось бы добавить пару вспомогательных методов в row или table, но так как они глубоко упрятаны в датасет, то остаётся только курить бамбук вместе с ООП в лице инкапсуляции.

В VS2005 можно

IT>- отсутвие поддержки перечислителей, соответственно абстракция от структуры данных тоже идёт лесом. Использование захаркоженных значений расползается по системе, в результате чего их потом приходится ловить и давить как тараканов. Весьма большой минус.

В VS2005 можно (не знаю, может даже в VS2003 тоже)

IT>- избыточная сериализация (в любой датасет всегда включается его схема).

сериализовать можно и без неё

<?xml version="1.0" standalone="yes"?>
<atm:InfrastructureDataSet xmlns:atm="urn:digiton-atm/infrastructure">
  <Radios xmlns="urn:digiton-atm/infrastructure">
    <RadioID>f3837198-d4a1-405a-9556-7923bc65ec87</RadioID>
    <RadioName>13</RadioName>
  </Radios>
  <Radios xmlns="urn:digiton-atm/infrastructure">
    <RadioID>28b2bd1f-dfcf-496c-87f8-f8b762f8df8d</RadioID>
    <RadioName>dio3</RadioName>
  </Radios>
  <Packs xmlns="urn:digiton-atm/infrastructure">
    <PackID>dd677ad6-d008-4250-9189-055a9111c71b</PackID>
    <RadioID>f3837198-d4a1-405a-9556-7923bc65ec87</RadioID>
    <PackName>Test</PackName>
    <UserPos>1</UserPos>
    <UserHide>false</UserHide>
  </Packs>
  <Packs xmlns="urn:digiton-atm/infrastructure">
    <PackID>05abaeb6-3f18-4deb-8eec-9781441c5d91</PackID>
    <RadioID>f3837198-d4a1-405a-9556-7923bc65ec87</RadioID>
    <PackName>Pack1</PackName>
    <UserPos>1</UserPos>
    <UserHide>false</UserHide>
  </Packs>
</atm:InfrastructureDataSet>

IT>- отсутсвие бинарной сериализации, что может увеличить трафик в разы.

В VS2005 можно

IT>- слабое повторное использование сущностей и как следствие тотальное дублирование. Можно конечно сделать xsd шаблоны и прикрутить import, но на этом как правило речь о визуальных средствах разработки заканчивается, рукова закатываются по самые уши и поехали выпиливать xsd схемы в рукопашную.

IT>Из всего выше сказанного можно сделать следующий вывод — однозначного ответа нет

У меня две параллельных модели, причём сущности загружаются из таблицы (то есть датасет первичен), — берём таблицу типизированного датасета и получаем массив сущностей, со своей, немного навороченной (в некоторых местах) обработкой свойств (например, если поле Age должно быть положительным).
Единственное, что здесь надо решить — генерацию кода этих самых сущностей. пока руками (в виду первой беты студии), а потом на R#, например. Процесс совсем не сложный, а плюсы обоих подходов радуют.

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

G2>Посколько Вы уже отвечали на подобный вопрос хочется уточнить, изменилось ли Ваше мнение по поводу Typed Dataset в связи с выходом VS 2005 и изменеиями в .Net 2.0(partirion class, TableAdapter и т.д).

Дело было почти два года назад. Тогда я только делал выбор. Сейчас я его уже однозначно сделал не в пользу датасетов. Главную проблему бизнес-объектов (маппинг) я решил, а больше мне жаловаться не на что.

Что касается новой версии датасетов, то я на них ещё не смотрел и пока не горю желанием. С интересом бы сам почитал что-нибудь на эту тему.

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


IT>Дело было почти два года назад. Тогда я только делал выбор. Сейчас я его уже однозначно сделал не в пользу датасетов.

Из — за их тяжеловесности?

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

_FR>У меня две параллельных модели, причём сущности загружаются из таблицы (то есть датасет первичен), — берём таблицу типизированного датасета и получаем массив сущностей, со своей, немного навороченной (в некоторых местах) обработкой свойств (например, если поле Age должно быть положительным).

Т.е. сначала закачиваешь данные в датасет, а потом переливаешь их в бизнес-объекты?

_FR>Единственное, что здесь надо решить — генерацию кода этих самых сущностей. пока руками (в виду первой беты студии), а потом на R#, например. Процесс совсем не сложный, а плюсы обоих подходов радуют.

Что именно ты собираешься генерировать?

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

IT>>Дело было почти два года назад. Тогда я только делал выбор. Сейчас я его уже однозначно сделал не в пользу датасетов.

G2>Из — за их тяжеловесности?

Я бы сказал из-за громоздкости.

Хорошее решение должно порождать простой прикладной код. Поэтому можно всегда сравнить два подхода просто написав на них одну и ту же задачу. Где прикладной код будет проще — то решение лучше. Если рассматривать датасеты vs бизнес-объекты в рамках стандартных средств, то проигрывая бизнес-объектам в простоте написания бизнес логики, датасеты вырываются далеко вперёд в том что касается чтения данных из БД и баиндинга этих данных на формы. Если решить эти две проблемы, датасеты однозначно проигрывают бизнес-объектам.

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

_FR>>У меня две параллельных модели, причём сущности загружаются из таблицы (то есть датасет первичен), — берём таблицу типизированного датасета и получаем массив сущностей, со своей, немного навороченной (в некоторых местах) обработкой свойств (например, если поле Age должно быть положительным).

IT>Т.е. сначала закачиваешь данные в датасет, а потом переливаешь их в бизнес-объекты?

Да. Закачиваю данные в датасет, потом, где надо (наличие логики на клиенте и некоторые расчёты удобнее вести со своими сущностями, хранящими в себе разные результаты вычислений, имеющие особые арифметические операции) получаю сущности из таблицы или другого набора строк. _По месту_, то есть не храню сущности постоянно, это у меня недолгоживущие объекты.

_FR>>Единственное, что здесь надо решить — генерацию кода этих самых сущностей. пока руками (в виду первой беты студии), а потом на R#, например. Процесс совсем не сложный, а плюсы обоих подходов радуют.

IT>Что именно ты собираешься генерировать?

Классы сущностей. Их должно быть несколько десятков, код у них на 60% одинаков (геттеры-сеттеры свойств, закрузка\сохранение) за небольшими исключениями (типы\имена полей). Каждый класс — partial, то есть каждый можно расширить в зависимости от смысла.

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

IT>>>Дело было почти два года назад. Тогда я только делал выбор. Сейчас я его уже однозначно сделал не в пользу датасетов.
G2>>Из — за их тяжеловесности?
IT>Я бы сказал из-за громоздкости.
IT>Хорошее решение должно порождать простой прикладной код. Поэтому можно всегда сравнить два подхода просто написав на них одну и ту же задачу. Где прикладной код будет проще — то решение лучше. Если рассматривать датасеты vs бизнес-объекты в рамках стандартных средств, то проигрывая бизнес-объектам в простоте написания бизнес логики, датасеты вырываются далеко вперёд в том что касается чтения данных из БД и баинга этих данных на формы. Если решить эти две проблемы, датасеты однозначно проигрывают бизнес-объектам.

Да, для обмена лучше использовать одно представление, для показа — другое, а для рассчётов — третье Остаётся их только подружить и не запутаться во взаимоотношениях.

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

IT>>Т.е. сначала закачиваешь данные в датасет, а потом переливаешь их в бизнес-объекты?

_FR>Да. Закачиваю данные в датасет, потом, где надо (наличие логики на клиенте и некоторые расчёты удобнее вести со своими сущностями, хранящими в себе разные результаты вычислений, имеющие особые арифметические операции) получаю сущности из таблицы или другого набора строк. _По месту_, то есть не храню сущности постоянно, это у меня недолгоживущие объекты.

А датасеты хранишь постоянно?

IT>>Что именно ты собираешься генерировать?

_FR>Классы сущностей. Их должно быть несколько десятков, код у них на 60% одинаков (геттеры-сеттеры свойств, закрузка\сохранение) за небольшими исключениями (типы\имена полей). Каждый класс — partial, то есть каждый можно расширить в зависимости от смысла.

Всё это давно умеет RFD.