DAL и BLL в .NET - PullRequest
Новая
       34

DAL и BLL в .NET

10 голосов
/ 17 января 2009

Существует это предложение DAL / BLL от Microsoft для приложений ASP.NET (2.0). Я знаю некоторые из альтернатив, и я прочитал соответствующие вопросы здесь на SO. Тем не менее, мне интересно, стоит ли реализовывать это предлагаемое решение в настоящее время, есть ли у вас какие-то недостатки?

Я хочу разработать компоненты DAL / BLL для внутреннего использования компанией, для доступа к данным клиентов и сотрудников и т. Д. Из различных приложений и сценариев. Однако, прежде чем я начну создавать такие вещи, я хочу быть уверен, что это решение «хорошо». Например, BLL передает таблицы данных вместо инкапсуляции чего-либо, у вас нет изолированных бизнес-объектов, которые содержат логику. По сути, это всего лишь тупой слой, который немного облегчает операции CRUD и позволяет привязывать данные для элементов управления.

Может ли кто-нибудь, кто имеет опыт в этой области, указать мне плюсы и минусы этого подхода?

Ответы [ 2 ]

12 голосов
/ 18 января 2009

Я полностью рекомендую НЕ ИСПОЛЬЗОВАТЬ БАЗЫ ДАННЫХ. Изучите реализацию разработки, управляемую доменом, чтобы вся ваша платформа работала с обычными объектами, которые вы можете передать в List <> или Queryable <>. DataTables - это мусор, который больше не следует даже включать в .NET.

Я бы также порекомендовал изучить возможность внедрения Dependency Injection / Inversion of Control, например Microsoft Unity или StructureMap, для создания слабосвязанного кода.

9 голосов
/ 17 января 2009

плюсы:
- простой подход, и некоторые отображения данных сделаны для вас с помощью таблицы данных.
- предлагает некоторые удобства для запуска запросов Select, Add, Update и Delete.
- может подойти для очень простого дизайна с несколькими столами.
- подходит для несамостоятельных ссылок на ER или ER с несколькими таблицами поиска и простыми / несколькими соединениями
- подходит там, где требуется простое хранилище данных. то есть. там, где к «бизнес-объектам» следует применять сложные идеи ОО, этот шаблон усложнит ситуацию.

минусы:
- большие модели OO будут бороться в этом образце
- сложные схемы ER со многими таблицами, сложными отношениями или требованиями к объектам OO не будут соответствовать этому шаблону. datatables не очень помогают в запросах объектов в коде, таких как LINQ.
- большинство запросов нужно писать вручную на SQL (включая объединения). да, вы можете использовать конструктор запросов, но это не очень помогает.
- в этом подходе много дублирования кода. как вы будете писать множество методов CRUD в ваших классах BLL (которые вам также нужно писать с нуля).

Вывод: это действительно зависит от ваших требований. если ваша реализация маленькая / простая, то это может быть хорошей идеей. но расти с маленькой идеей будет трудно с этим подходом. более ОО-подход намного лучше настроит вас для рефакторинга / расширения позже. этот образец также стар / устарел. Запросы объектов IQueryable / LINQ более популярен и вскоре станет более широким стандартом. Я бы посоветовал тебе запрыгнуть в этот вагон. это будет лучше для вашего личного развития в долгосрочной перспективе тоже. : D

некоторые ссылки:

...