Поделитесь соображениями - как вы считаете лучше создать модель для такого DAL/BLL. Возьмём к примеру базу данных PUBS с таблицами authors и titleauthor, которые связаны one-to-many: один автор может иметь много книг (titles). Требуется создать простую форму с AuthorsGridView и с AuthorTitlesGridView.

Вариант1: использовать SqlDataSource
Вариант2: использовать ObjectDataSource

Если экстраполировать сценарий на Большую систему, то как я понял рекоммендуют выделять всю логику в отдельный слой DAL/BLL. Значит вариант1 отпадает. (опровергнете если не так)

Для Варианта2 нужно будет (безусловно облегчает работу) создавать типизированный DataSet с TableAdapter-ами. Здесь возникает пара вопросов - имеет ли смысл создавать DataSet для каждый таблицы в отдельности или скинуть TableAdapter-ы для всех таблиц в один DataSet. Ведь в итоге если нам нужна одна DataTable, то заполняется только она а не весь DataSet.

Далее, стали бы вы создавать дополнительные классы для работы с данными через уже обьявленный DataSet и TableAdapter-ы? Или же стали бы работать напрямую с DataSet-ом с CodeBehind-а вашей страницы? (если да, то почему)

Если бы вы стали создавать дополнительную иерархию классов (Custom Classes), типа AuthorCollection - коллекция классов Author, TitleCollection - коллекция классов Title и т.д... То каких типов вы сделали бы ваши классы и как бы вы их увязали между собой и с раннее созданным DataSet-ом с TableAdapter-ами ?

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

Имеется ли вообще нужда создавать подобные иерархии классов если всё равно придётся работать через типизированные DataSet-ы где всё это уже определено?

Спасибо.


 

Дополню себя след. определением:
A business logic layer is similar to a DAL in that it exposes stateless methods to ObjectDataSource for binding controls in Web pages. However, instead of returning ADO.NET results directly, it typically returns strongly-typed objects that represent the business entities used by the application. This decouples the presentation layer from the schema of the underlying data store, making it easier to maintain the data access portion of your site separately from the pages that consume the data. With a properly architected middle-tier, you could change the underlying data store to a completely different schema without having to update the individual pages in your application.

Что в общем то меня и интересует. Если начать создавать "stronly typed objects" и "strongly typed collections", тогда получается двойная работа и дупликация кода, что усложняет поддержку программы, а именно:

Какой смысл создавать класс Author а затем создавать класс-коллекцию этого класса AuthorCollection и обявлять там поля и property если всё это уже суwествует в типизированном датасете который визард создаёт автоматом?

К примеру датасет AuthorsDataSet, у него есть ВСЁ что может понадобится, authorsDataTable, authorsRow и т.д.. где authorsRow это полноценный обьект соответствующий записи в таблице authors, а authorsDataTable это по-сути коллекция таких обьектов.

a зaчем ? ты прoверял, нaпример скoлькo зaнимaет в пaмяти тaкoй дaтaсет ?
- отложим споры о перформансе в сторону. меня в данный момент это не волнует, меня интересует только дизайн, архитектура.
 
кoллекцию сoздaвaть в дaннoм случaе незaчем, мoжнo oбoйтись List<T> или нa худoй кoне Array.
- Насчёт коллекции, ок, в 2.0 используем Generics.
 
крoме тoгo - зaвтрa тебя пoпрoсят к примеры чтoбы пoлoвинa aвтoрoв брaлaсь не из бaзы a из Active Directory, пoсмoтрим кaк wizard спрaвится с тaкoй зaдaчей
- ну это понятно... я не хочу сейчас вдаваться в миллионы различных теоретически возможных вариантов,
меня интересует конкретный сценарий - база данных PUBS на SQL Server. всё.

Повторюсь, типизированные датасеты придумали не просто так, усовершенствовали их в 2.0 не просто так.

Типизированный датасет заключает в себе полную обьектную модель рекорда, таблицы, и даже нескольких таблиц.

Я не могу усмотреть сценарий когда может понадобиться создават обьект дупликат Author, который по сути дела будет являться недоделанной копией обьекта authorsDataRow (дочерний обьект таблицы authorsDataTable нашего типизированного датасета).

То есть вы напрочь отрицаете использование типизированных датасетов для этого сценария?

Но тогда сводятся на нет практически всё то чем ASP.NET 2.0 отличается от ASP.NET 1.1 для работы с данными.

up

Ладно, приведу пример. Возьмём базу данных pubs и таблицу authors. Предположим на странице есть контрол GridView и ObjectDataSource. Пишу BL, в нём я могу по разному обьявить один и тот же метод который мне нервнёт необходимые данные. Генерируем визардом DAL (типизированный датасет для нашей таблички AuthorsDataSet), далее переключаемся на BLL и создаём метод GetAuthors() который вернёт нужные нам данные:

Вариант1 - Предварительно строим custom class Authors (с полями как у таблицы), далее используя наш датасет мы заполняем strongly-typed collection из обьектов типа Author:

Public Function GetAuthors() As List(Of Author)
Dim adapter As New AuthorsDataSetTableAdapters.authorsTableAdapter
Dim table As AuthorsDataSet.authorsDataTable = adapter.GetAuthors()
Dim authors As New List(Of Author)
For Each row As AuthorsDataSet.authorsRow In table
authors.Add(New Author(row("au_id"), row("au_lname"), row("au_fname"), row("phone"), row("address"), row("city"), row("state"), row("zip"), row("contract")))
Next
Return authors
End Function
Или же Вариан2 - Никаких дополнительных классов Author нам строить не надо, просто используем наш датасет и возвращаем authorsDataTable (которая по сути деля является strongly-typed enumerable collection обьектов authorsDataRow, authorsDataRow - это обьект каждого автора в отдельности):
 
 Public Function GetAuthors() As AuthorsDataSet.authorsDataTable
Dim adapter As New AuthorsDataSetTableAdapters.authorsTableAdapter
Dim table As AuthorsDataSet.authorsDataTable = adapter.GetAuthors()
Return table
End Function
По-моему второй вариант намного короче, понятнее и легче поддерживать. Если я меня название поля в таблице, то мне надо переписывать первый вариант, в то время как второй остаётся без изменений.
 
Хотелось бы услышать аргументированное противоположное мнение. Спасибо.

Иными словами вы считаете что Майкрософт "ошибся" создавая всю мощнейшую инфраструктуру по работе с типизированными датасетами ? Все статьи, учебники, вебкасты по работе с данными тоже ошиблись используя систему визуального программирования и DAL а базе типизированных датасетов?

Извините, но ваш ответ мне кажется неубедительным.

Я конечно понимаю что "каждый настоящий программист должен писать в машинных кодах", но это было бы кащунством не использовать такие мощные возможности для работы с базами данных как датасеты. Для кого же по вашему всё это было создано и почему во всех мануалах и т.д. только об этом и говориться?

Вообщем то я ещё больше убедился в том что использование типизированных датасетов в качестве DAL гораздо практичнее и удобнее чем писать их жалкое корявое подобие вручную.

 Dima_XY3, статью прочитал, занятно. Я уже читал на эту тему раньше. Однако скажем прямо - это в будущем, на Сейчас ещё не существует Обьектно-Ориентированных баз данных ODBMS (когда будет тогда и будем это обсуждать), на сегодня мы имеем ASP.NET 2.0 и Visual Studio 2005 которые приспособлены для работы с RDBMS. И на мой взгляд наиболее удобный механизм работы с данными на сегодня - это типизированные датасеты. Драг-н-дропнул DataSet и всё - готовый DAL !! Ну разве не прелесть.

Потом пишешь BBL который использует этот DataSet-DAL для работы с данными и всё. Не пойму в чём проблема... :)

Дима, спасибо, я уверен что есть хорошие прогрессивные продукты на рынке. Но я не сам себе хозяин, что на работе имеем, с тем и работаем. A имеем мы стандартный комплект - базу данных на MS SQL Server и Visual Studio 2005. На этом и будем писать все проекты.

Dimon aka Manowar, спасибо. Я согласен с тем что есть минусы и есть плюсы. Если отложить в сторону вопрос об performance, мне просто хотелось бы получить конкретный пример когда с точки зрения написания и управления кодом типизированные датасеты дали бы сбой. Заметьте что время и усилия потраченные на написание вручную DAL это тоже очень существенный фактор.

Давайте к примеру возьмём конкретную ситуацию - базу данных  pubs, таблицу authors. Там нет 100 тыщ рекордов. Могли бы вы мне показать и доказать в каких случаях использование типизированного датасета даёт сбой (иными словами не практично и неоправданно, я не имею в виду performance, а именно написание и управление кодом, поддержка кода в будущем). Свои доводы в пользу типизированного датасета я уже привёл выше.

Мне хотелось бы услышать аргументированные доводы (performance времмено оставим в стороне).

Спасибо.

up