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

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

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

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

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

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

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

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

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

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

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