Asp.net DAL и BLL предпочли шаблонный подход

Question

Я занимаюсь разработкой нескольких небольших приложений ASP.NET и хотел бы знать, какой шаблон. подход вы используете в своих проектах.

В моих проектах используются базы данных, использующие уровни доступа к данным и бизнес-логики.

Подход к доступу к данным, который я использовал до сих пор, следующий (я читал в какой-то книге и мне понравился):

Для слоя DAL:
Создание абстрактного класса, который определит все методы манипулирования базой данных для реализации. Абстрактный класс будет содержать статическое свойство «Instance», которое будет загружать (если instance == null) экземпляр (Activator.CreateInstance) нужного типа (класс, который его реализует).

Создавая классы, реализующие этот абстрактный класс, реализация будет соответствовать используемым базам данных (SQL, mySQL и т. Д.).
Благодаря этому я могу создавать различные реализации в зависимости от используемой базы данных.

Для слоя BLL:
Класс, который инкапсулирует все все извлеченные поля и статические методы, которые будут вызывать классы DAL.

Это хороший подход?
Что вы предпочитаете использовать в таких ситуациях?

Answer 1

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

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

public class Global HttpApplication {

    // This would really be a property
    // It's also unfortunate this has to be static, but you're stuck with
    // default constructors for ASP.NET pages, so there's no alternative.
    public static BusinessLayerClass BusinessLayer;

    protected void Application_Start(object sender, EventArgs e) {
         AbstractDataAccessLayer dataAccess = new ConcreteDataAccessLayer();
         Global.BusinessLayer = new BusinessLayerClass(dataAccess);             
    }
}

Страницы затем используйте это так:

public void PerformSomeBusinessFunction() {
    Global.BusinessLayer.DoSomething();
}

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

Общий принцип здесь называется " внедрение зависимостей " (иногда его называют "инверсией управления", что является еще более общим принципом, лежащим в основе DI.)

Если это ручное внедрение зависимостей начинает становиться громоздким, рассмотрите возможность использования инфраструктуры внедрения зависимостей (люди также называют эти «контейнеры IoC»).

Answer 2

Это хороший подход. Я тоже использую этот подход. Я использую корпоративную библиотеку для DAL. недавно я обнаружил, что использование L2S полезно для DAL.

Я тоже рекомендую использовать NHibernate.

Answer 3

Хорошо, я расскажу вам о нескольких подводных камнях с вашим подходом и о том, как я обычно это делаю.

Ловушки

Ваше свойство экземпляра DAL выглядит как умный, странный способ создания синглтона. Следует помнить, что запросы к вашему веб-серверу могут обрабатываться асинхронно, поэтому, если ваш вызов Activator.CreateInstance займет некоторое время, это может привести к некоторым проблемам.

Ваш BLL-слой страдает от той же проблемы, я думаю. Такую инициализацию лучше выполнять при запуске приложения (не могу вспомнить точное имя).

То, что вы в основном используете здесь, это DI-принцип и шаблон репозитория. И то, и другое прекрасно, и позволит проводить модификации и тестирование, так как ваш абстрактный класс будет в DAL, а ваши BLL-методы будут вызывать DAL-классы, ваш BLL должен знать о DAL. Это может быть проблемой. Вместо этого вы можете создать промежуточную библиотеку с интерфейсом для вашего абстрактного класса.

Что я обычно делаю

Мне действительно не нравятся «слои» в приложении, поскольку зачастую трудно различить различные типы функциональности и то, в каком направлении они должны знать о других слоях. Я использую другой подход, который я не совсем уверен, называется ли что-то, но я называю это кругом зависимости :) По сути, это как доска для дротиков, где самые внутренние сборки ничего не знают о внешнем.

В вашем типичном веб-приложении для блогов я бы сделал что-то вроде этого:

BlogEngine.Core содержит POCO-сущности различных элементов (Post, User, Comment, что угодно), а также различные интерфейсы к службам. Эти сервисы могут включать IEmailService, IBlogRepository, IUserManagement и т. Д. И т. Д. ... Теперь я делаю сборку BlogEngine.Infrastructure.Persistence, которая знает о .Core и реализует IBlogRepository. Я делаю то же самое для всех других услуг.
Теперь - вашему BlogEngine.Web нужно только сослаться на вашу .Core сборку и сборку IoC-framework, которая позаботится обо всех ваших зависимостях. Если я хочу обновить сообщение, я могу сделать myIOC.GetInstance<IBlogRepository>().SaveOrUpdatePost(newPost);.
Допустим, вы хотите уведомить авторов, когда люди публикуют комментарии в своих блогах. Вы можете реализовать эту логику в .Core как Notifier -класс. Этот класс может разрешить IEmailService, а затем отправлять любое электронное письмо, которое вам нужно.

Суть в том, что у вас есть ядро, которое никогда не должно меняться в вашем домене. Тогда вы получили инфраструктурные сборки, которые знают только о Core. У вас есть ваше веб-приложение, которое знает о Core и IOC-фреймворке - и у вас есть ваш IOC, который знает обо всем, и ему разрешено это делать :) Если вам нужно внести изменения, есть вероятность, что оно находится в сборках инфраструктуры и так что вам нужно всего лишь обновить настройки IOC и реализовать какие

Надеюсь, это имеет смысл, если нет, пожалуйста, оставьте комментарий, и я постараюсь объяснить дальше:)

Удачи