BLL — это слой бизнес-логики
DAL — это уровень доступа к данным
Трёхуровневая архитектура ASP.NET (DAL, BLL, UI)
Графика представляет собой трёхслойную структуру. Веб — это уровень USL
web –> blll –> dal
| | |
| V |
+–> модель <—+
1. Трёхуровневая архитектура
1. Слой презентации (USL): в основном представляет метод WEB, но также может быть выражен в режиме WINFORM. Если логический слой достаточно надёжен и хорошо зарекомендовался, он будет работать идеально независимо от того, как определяется и изменён уровень производительности.
2. Слой бизнес-логики (BLL): главным образом для конкретных задач его также можно понимать как работу слоя данных и логическую обработку бизнеса данных. Если слой данных — это строительные блоки, то логический слой — это строительный блок.
3. Слой доступа к данным (DAL): Это в основном операционный слой исходных данных (в виде базы данных, текстового файла или другой формы хранения данных), а не исходные данные, то есть работа с данными, а не база данных, а именно слой бизнес-логики или презентации
Предоставление услуг передачи данных.
2. Специфическое различие
1. Уровень презентации: в основном принимает запросы пользователя и возвращает данные, предоставляя клиенту доступ к приложению.
2. Слой бизнес-логики: главным образом отвечает за работу слоя данных, то есть за сочетание некоторых операций на уровне данных.
3. Слой доступа к данным: Он в основном зависит от того, содержит ли ваш слой данных логическую обработку; на самом деле его функции в основном выполняют различные операции над файлом данных и не беспокоятся о других операциях.
3. Краткое содержание
Трёхуровневая структура — это строгий иерархический подход, то есть доступ к слою доступа к данным (DAL) может быть доступен только на уровне бизнес-логики (BLL), а к слою бизнес-логики — только на уровне презентации (USL). Некоторые трёхслойные структуры также добавляют другие слои, такие как Factory и Model, которые фактически являются расширением и приложением на основе этих трёх слоёв.
Простая трёхслойная программа обычно включает несколько проектов веб-модели DAL BLL, и их взаимные ссылки следующими
1) WEB ссылки на BLL, модель
2) BLL ссылается на DAL, модель
3) DAL ссылается на модель
4) Модель не содержит ссылок
Что касается трёхуровневой архитектуры, все знают, что это уровень производительности (UI), бизнес-логический уровень (BLL) и уровень доступа к данным (DAL), и существует множество способов разделить каждый слой. Но как писать конкретный код и на каком уровне эти файлы считаются — неясно. Ниже приведён простой пример, который поможет вам попрактиковаться в трёхуровневом архитектурном проекте; этот пример имеет только одну функцию — простое управление пользователями.
Сначала создайте пустое решение и добавьте следующие элементы и файлы
1. Добавить проект ASP.NET веб-приложения, назвать его UI и создать новый User.aspx веб-формы (включая User.aspx.cs)
2. Добавить проект ClassLibrary, назвать его BLL и создать новый файл Class UserBLL.cs
3. Добавить проект ClassLibrary, назвать его DAL и создать новый файл Class UserDAL.cs. Добавьте ссылку на SQLHelper. (Это курс Microsoft по доступу к данным, или вы можете написать весь код доступа к данным напрямую.) Обычно я использую класс DataAccessHelper, который пишу).
4. Добавить проект ClassLibrary, назвать его Model и создать новый файл типа Class UserModel.cs
5. Добавьте проект ClassLibrary, назовите его IDAL и создайте новый интерфейсный файл IUserDAL.cs
6. Добавить проект ClassLibrary и назвать его ClassFactory
Думаю, вы заметили, что это ничем не отличается от примера Petshop, и всё проще, потому что я также изучаю трёхслойную архитектуру через Petshop. Однако некоторые друзья могут быть расплывчаты относительно уровня этих проектов и взаимоотношений между ними, вот объяснение их по одному:
1. User.aspx и User.aspx.cs
Оба документа (и элементы, к которым он принадлежит, а также ниже, не будут повторяться) являются частью слоя презентации. User.aspx проще понять, потому что это отображаемая страница. User.aspx.cs некоторые считают, что его не следует учитывать, а включать в бизнес-логический слой. Если вы не занимаетесь слоями, то нет проблем с тем, чтобы User.aspx.cs управлять бизнес-логикой и даже управлять базой данных, но если вы делаете слои, этого делать не должно. В иерархической структуре User.aspx.cs должна заниматься только контентом, связанным с отображением, и ничего другого не должно быть охвачено.
Например, если реализовать функцию отображения пользователей в виде списка, то работу по извлечению информации выполняет BLL, и после того, как пользовательский интерфейс (в данном случае это User.aspx.cs) вызывает BLL для получения UserInfo, он связывается с управлением данными User.aspx через код, чтобы реализовать отображение списка. В этом процессе, User.aspx.cs он не играет роли в пользовательском интерфейсе, он используется только для передачи данных, и поскольку большая часть самого кода реализована именно так, некоторые считают, что User.aspx.cs не следует считать UI, а нужно объединять с BLL для логической обработки. Далее было введено новое требование добавить иконку перед каждым пользователем, чтобы ярко отражать пол пользователя, а для лиц младше 18 лет она была представлена дочерним значком. Реализация этого требования — это поворот User.aspx.cs, и в данном случае User.aspx.cs оно имеет реальное применение.
2、NewBLL.cs
Добавьте следующие методы:
публичный IList GetUsers(): Возвращает список всей информации о пользователях
публичный UserInfo GetUser(int UserId): Возвращает данные указанного пользователя
публичный bool AddUser(UserInfo User): Добавлена информация о пользователе
публичный bool ChangeUser(UserInfo User): Обновляет информацию о пользователях
public void RemoveUser(int UserId): удаляет информацию о пользователях
Этот файл относится к уровню бизнес-логики и предназначен для обработки операций, связанных с бизнес-логикой. Многие могут считать, что единственное применение этого слоя — пересылка данных с уровня производительности на уровень. Действительно, таких случаев много, но это может означать лишь то, что проект относительно прост, или что отношения между самим проектом и бизнесом не тесно интегрированы (как в нынешнем популярном MIS), поэтому бизнес-слой не имеет никакого отношения и играет лишь роль пересылки. Но это не значит, что бизнес-слой становится лишним: по мере роста проекта или появления новых деловых отношений бизнес-уровень будет отражать свою роль.
Наиболее вероятная ошибка здесь — назначить код операций данных на бизнес-логический уровень, а базу данных — в качестве слоя доступа к данным.
Например, некоторые друзья считают, что слой BLL не имеет значения, но просто загружают данные DAL и пересылают их в интерфейс без какой-либо обработки. Посмотрите на этот пример
Слой BLL
SelectUser(UserInfo userInfo) получает данные пользователя на основе имени пользователя или электронной почты.
IsExist (UserInfo userInfo) определяет, существует ли указанное имя пользователя или электронная почта.
Затем DAL также предоставляет соответствующий метод для вызова BLL
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
Таким образом, BLL играет только роль передачи.
Но если вы это сделаете:
Блл. IsExist(Userinfo userinfo)
{
UerInfo пользователь = DAL. SelectUser(Пользователь);
возврат (userInfo.Id != null);
}
Тогда DAL не нужно реализовывать метод IsExist(), и в BLL есть логический код обработки.
3、UserModel.cs
Сущность, вы можете думать, что это сложно стратифицировать. Включая меня, я понял это так: UI?àModel?àBLL?àModel?àDAL, поэтому считается, что Модель служит мостом для передачи данных между уровнями. Но здесь мы думаем не о простом, а о сложности.
Что такое Model? Ничего! В трёхуровневой архитектуре она заменяема. На самом деле это самое базовое в объектно-ориентированном программировании: классы. Таблица — это класс, новости — тоже класс, интеллект, строка, дубли и т.д. тоже классы, это просто класс.
Таким образом, положение модели в трёхслойной архитектуре совпадает со статусом переменных, таких как int и string, и она не имеет другого назначения: используется только для хранения данных, но хранит сложные данные. Поэтому, если объекты в вашем проекте очень простые, вы можете напрямую передавать несколько параметров без модели, чтобы создать трёхслойную архитектуру.
Так зачем же нужна модель и каковы её преимущества? Вот что приходит в голову, когда задумываешься о вопросе, вставленном здесь:
Может ли Модель играть большую роль в передаче параметров на каждом уровне?
При передаче параметров между слоями можно сделать следующее:
AddUser(userId, userName, userPassword,...,)
Это может быть и так:
AddUser(userInfo)
Какой из этих двух методов лучше? На первый взгляд, это должно быть второе гораздо лучше.
Когда передавать параметры между слоями с нормальными типами переменных (int, string, guid, double) и что передавать с Model? Следующие методы:
SelectUser(int UserId)
SelectUserByName (имя пользователя строки)
SelectUserByName (имя пользователя строки, пароль от строки)
SelectUserByEmail (строковое письмо)
SelectUserByEmail (строковое письмо, пароль от строки)
Его можно резюмировать так:
SelectUser(userId)
SelectUser(пользователь)
Здесь мы используем объект пользовательской модели для включения четырёх комбинаций режимов: имя пользователя, пароль и электронная почта. UserId также можно объединить с пользовательским элементом, но другие BLL в проекте реализуют интерфейсы с id-параметрами, поэтому этот элемент тоже сохраняется.
userInfo передаётся, так что как с этим справиться, это должно быть в порядке, есть конкретный код, который нужно решить.
Здесь он обрабатывается в таком порядке
Сначала проверьте, есть ли у вас и имя пользователя, и пароль, затем есть ли у вас и email, потом есть ли у вас имя пользователя, а потом — есть ли у вас email. Обрабатывается последовательно.
Таким образом, если в будущем добавляется новый контент — членскую карту (номер), нет необходимости менять интерфейс, достаточно добавить поддержку номера в DAL-коде, а затем добавить производительность и обработку содержимого членской карты на переднем плане.
4、UserDAL.cs
публичный IList SelectUsers(): Возвращает список всей информации о пользователях
публичный UserInfo SelectUser(int UserId): Возвращает доверенную информацию указанного пользователя
публичный bool InsertUser(UserInfo User): Добавлена информация о пользователе
публичный bool UpdateUser(UserInfo User): Обновляет информацию о пользователях
public void DeleteUser(int UserId): удаляет информацию пользователя
Многие не могут понять слой доступа к данным, какая часть считается слоем доступа к данным? Некоторые считают, что база данных — это слой доступа к данным, что не совсем понятно: DAL — это уровень доступа к данным, а не слой хранения данных, поэтому база данных не может быть именно этим уровнем. Роль SQLHelper — сократить повторяющееся кодирование и повысить его эффективность, поэтому, если я привык заботиться об эффективности или использовать источник данных, не связанный с базой данных, я могу отказаться от SQLHelper — части, которую можно отбросить по желанию, как она может стать слоем трёхслойной архитектуры.
Он может быть определен следующим образом: код, связанный с операциями с источником данных, должен быть помещён в слой доступа к данным, который относится к углу доступа к данным
5、IUserDAL
Интерфейс слоя доступа к данным — это ещё одна лишняя вещь, потому что Petshop приносит его вместе с ClassFactory и ClassFactory, поэтому некоторые проекты делают эти две вещи независимо от того, нужно ли им поддерживать несколько источников данных, а некоторые даже не строят ClassFactory, а только собирают IDAL, и тогда "IUserDAL iUserDal = новый UserDAL(); Я не знаю, что это значит. Это полностью тигр, а не антисобака.
Многие здесь заблуждаются, что существует такая связь: BLL?àIDAL?àDAL, считая, что IDAL служит мостом между BLL и DAL, а BLL называет DAL через IDAL. Но реальность такова, что даже если запрограммировать так: «IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); При выполнении «iUserDal.SelectUsers()» на самом деле выполняется экземпляр UserDAL, а не экземпляр IUserDAL, поэтому положение IDAL на третьем уровне связано с уровнем DAL.
В приведённом выше введении в основном объясняется иерархия трёхуровневой архитектуры. На самом деле, у меня есть способ оценить, является ли трёхслойная архитектура стандартной, то есть полная замена любого из трёх уровней не повлияет на остальные два, и такая структура в основном соответствует стандарту трёхслойного уровня (хотя реализовать её сложнее ^_^). Например, если вы меняете проект с B/S на C/S (или наоборот), то BLL и DAL не нужно менять, кроме интерфейса; Или заменить SQLServer на Oracle, просто заменить SQLServerDAL на OracleDAL, никаких других операций не требуется и так далее. Изначально я хотел добавить какой-то конкретный код в статью, но не считаю это необходимым, если вы считаете нужным — я добавлю его.
Резюме: Не думайте, что слой ненужен только потому, что он для вас бесполезен, или его особенно просто реализовать, отказаться от него или использовать для других целей. Пока слои выполняются, независимо от их количества, каждый слой должен иметь чёткое назначение и функцию, и не должен подвергаться влиянию самого процесса, в результате чего один и тот же тип файла оказывается в разных слоях. Не позволяйте одному и тому же слою реализовать разные функции. |
Опубликовано 07.05.2015 10:53:35
|
|
|
