DAL и BLL в .NET.

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

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

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

Ответы

Ответ 1

плюсы:
- простой подход, и некоторое отображение данных выполняется для вас с данными datatable.
- предлагает некоторые удобства для запуска выбора, добавления, обновления и удаления запросов.
- может быть подходящим для очень простого дизайна с несколькими таблицами.
- подходит для не-саморегуляции ER-дефигментов или ER с небольшим количеством таблиц поиска и простых/нескольких объединений
- подходит, когда требуется простой хранилище данных. то есть. где комплексные идеи OO должны применяться к" бизнес-объектам", этот шаблон затруднит ситуацию.

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

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

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

Ответ 2

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

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