Читаю Марко Беллиньясо (Разработка web-приложений в среде ASP.NET 2.0 Задача-проект-решение).
Считаю, что применяемая его архитекрура доступа к данным слишком сложна (хотя он воспивает всю книгу о простоте...=) ).
Я пытаюсь реализовать классы доступа к данным как можно меньше зависящие от конкретной БД.
Может быть кто то приведет пример хорошо спроетированных слоев?
Насколько возможно отделить бизнес логику от уровня доступа к данным при использовании Linq в своих приложениях?

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

DNN>Насколько возможно отделить бизнес логику от уровня доступа к данным при использовании Linq в своих приложениях?

Причём тут Linq? Linq не ORM.

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

DNN>>Насколько возможно отделить бизнес логику от уровня доступа к данным при использовании Linq в своих приложениях?

A>Причём тут Linq? Linq не ORM.

Причём тут ORM? ORM не DAL.

Здравствуйте, adontz, Вы писали:
A>Причём тут Linq? Linq не ORM.

Используя Linq мы на выходе получаем сразу готовые объеты...

Вот нашел интерестную статейку : http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

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

DNN>>>Насколько возможно отделить бизнес логику от уровня доступа к данным при использовании Linq в своих приложениях?

A>>Причём тут Linq? Linq не ORM.
IT>Причём тут ORM? ORM не DAL.

DAL, BLL и ORM как минимум связаны. Linq этому всему перпендикулярен, но часто путаем с ORM.

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

A>>>Причём тут Linq? Linq не ORM.
IT>>Причём тут ORM? ORM не DAL.

A>DAL, BLL и ORM как минимум связаны. Linq этому всему перпендикулярен, но часто путаем с ORM.

Блин, ну я вот так и думал... вопрос не в этом....

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

DNN>Вот нашел интерестную статейку : http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
Именно. Можно дополнить еще вот этим: Не повторяйте DAO! Создание обобщенного типизированного DAO с Hibernate и Spring AOP — принцип универсальный, ложится как на любой тип хранилища, так и интегрируется с ORM.

По поводу ASP.NET:

• если по началу сложно, то проще всего обезопасить самого себя так: попросту разделить DAL, BLL, PL по разным сборкам — сборки BLL, PL не должны пользоваться никакими компонентами доступа к данным хранилищ напрямую, достаточно убрать соответствующие references;
  
• по возможности отказаться от использования классов пространства имен System.Data, к примеру, DataSet;
  
• если используется напрямую ADO.NET, то хотя бы работать с ним по обобщенному варианту, но лучше, конечно, ORM;
  
• если очень хочется привязки данных, то хотя бы отказаться от SqlDataSource в сторону ObjectDataSource.

DNN>Читаю Марко Беллиньясо (Разработка web-приложений в среде ASP.NET 2.0 Задача-проект-решение).
DNN>Считаю, что применяемая его архитекрура доступа к данным слишком сложна (хотя он воспивает всю книгу о простоте...=) ).
А что там у него?

Здравствуйте, rsn81, Вы писали:
DNN>>Читаю Марко Беллиньясо (Разработка web-приложений в среде ASP.NET 2.0 Задача-проект-решение).
DNN>>Считаю, что применяемая его архитекрура доступа к данным слишком сложна (хотя он воспивает всю книгу о простоте...=) ).
R>А что там у него?

Ну вот на примере управления статьями:
есть общий класс DataAccess <- ArticlesProveder <-SqlArticleProvider (Все это только DAL)
на уровне бизнес логики: BizObject <- Articles.BaseAticles <- Articles.Article
Может быть это и приемлимо для когото, но не для новичков (к которым я отношусь)... =)

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

DNN>Ну вот на примере управления статьями:
DNN>есть общий класс DataAccess <- ArticlesProveder <-SqlArticleProvider (Все это только DAL)
DNN>на уровне бизнес логики: BizObject <- Articles.BaseAticles <- Articles.Article
DNN>Может быть это и приемлимо для когото, но не для новичков (к которым я отношусь)... =)
А как, вам кажется, нужно сделать?

Здравствуйте, rsn81, Вы писали:
R>А как, вам кажется, нужно сделать?

Поверьте, если бы я знал как надо сделать, я бы не стал создавать этот топик...=)

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

DNN>Поверьте, если бы я знал как надо сделать, я бы не стал создавать этот топик...=)
А какие тогда у вас варианты? Читать и пытаться понять... что не понятно можно или попросту для начала принимать на веру (верить авторитетам) [по уму, все это должен делать ваш непосредственный технический руководитель], или рисковать и делать так, как понятно лично вам на текущем уровне развития (здесь вы теряете существующие наработки, но приобретаете понятность code design лично для вас на первом этапе) — постепенно нужно отходить от второго к первому.

Можно почитать вот это:
Вопрос начинающего

Автор:
Дата: 13.06.07

Data Access Layer и Model Layer

Автор:
Дата: 10.09.07

Воспользовавшись поиском, можно найти еще возок и маленькую тележку тем про разделение приложения на слои.

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

DNN>Я пытаюсь реализовать классы доступа к данным как можно меньше зависящие от конкретной БД.

Суть отделения бизнес логики от доступа к данным совсем не в том чтобы можно было абстрагироватся от конкретной БД. Найди определение термина слой(layer). Подумай над тем как выделение конкретного слоя позволяет инкапсулировать в нем некоторую функциональность. И уменьшить связанность системы в целом. Тут ещё нужно вспомнить GRASP паттерн low coupling/high cohesion.
Так вот задача отделения бизнес логики от уровня доступа к данным, это только частный случай выделения слоев в системе.
Некоторое понимание слоев приходит после прочтения материала по MVC.

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

B> Суть отделения бизнес логики от доступа к данным совсем не в том чтобы можно было абстрагироватся от конкретной БД. Найди определение термина слой(layer). Подумай над тем как выделение конкретного слоя позволяет инкапсулировать в нем некоторую функциональность. И уменьшить связанность системы в целом. Тут ещё нужно вспомнить GRASP паттерн low coupling/high cohesion.
B> Так вот задача отделения бизнес логики от уровня доступа к данным, это только частный случай выделения слоев в системе.
B> Некоторое понимание слоев приходит после прочтения материала по MVC.

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

DNN>Насколько возможно отделить бизнес логику от уровня доступа к данным при использовании Linq в своих приложениях?

Имхо это путь в другую сторону.
При использовании Ling вы можете только отделить функциональную логику от логики хранения, но не бизнес-логику от БД.
Абстрагированием от БД занимается соответствующий блок в Enterprise Library.

Здравствуйте, DioNNis, Вы писали:
B>> Суть отделения бизнес логики от доступа к данным совсем не в том чтобы можно было абстрагироватся от конкретной БД. Найди определение термина слой(layer). Подумай над тем как выделение конкретного слоя позволяет инкапсулировать в нем некоторую функциональность. И уменьшить связанность системы в целом. Тут ещё нужно вспомнить GRASP паттерн low coupling/high cohesion.
B>> Так вот задача отделения бизнес логики от уровня доступа к данным, это только частный случай выделения слоев в системе.
B>> Некоторое понимание слоев приходит после прочтения материала по MVC.

DNN>Так вот вопрос в том, насколько это необходимо с Linq и маппнгом данных, когда за тебя строятся все классы объектов, который обладают даже избыточной функциональность... (я говорю про свое приложение)

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

Любую проблему архитектуры системы можно решить введением нового логического слоя. Кроме проблемы слишком большого количества слоёв. (с) НеПомнюКто

R>Именно. Можно дополнить еще вот этим: Не повторяйте DAO! Создание обобщенного типизированного DAO с Hibernate и Spring AOP — принцип универсальный, ложится как на любой тип хранилища, так и интегрируется с ORM.

Не понятен смысл демонстрации Hibernate+Spring применительно к этой статье.
По сути дела Spring в статье используется лишь как IoC-паттерн, в таком случае достаточно более легковесного и простого Castle. Именнованные же запросы в Hibernate-маппинг встроены давно.

Здравствуйте, снежок, Вы писали:

С>Не понятен смысл демонстрации Hibernate+Spring применительно к этой статье.
С>По сути дела Spring в статье используется лишь как IoC-паттерн, в таком случае достаточно более легковесного и простого Castle. Именнованные же запросы в Hibernate-маппинг встроены давно.
Ссылку дал на статью просто потому что там объясняется, как построить обобщенный DAO, здесь изобретать нечего собственно, а вот привязка к конкретным поставщикам данных или ORM — это уже дело каждого.