Я всегда хотел написать относительно полное и совершенное обобщение. Но, поразмыслив, не знал, с чего начать. Как говорится, лиха беда начало. Сегодня я разобрал свои сумбурные мысли. Что ж, я так и не разобрал их как следует. Буду говорить о том, что придёт в голову.

Новички действительно не понимают:

  • 1. Что такое трёхуровневая архитектура?
  • 2. Зачем использовать трёхуровневую архитектуру?
  • 3. В чём разница между трёхуровневой и ранее использовавшейся двухуровневой архитектурой? В чём её преимущества?
  • 4. Как хорошо изучить трёхуровневую архитектуру? Как применять трёхуровневую архитектуру? ……

В этом посте блога я объясню их по порядку. Я и сам знаю об этом лишь немного, так что прошу прощения!!!

Учитель Ми всегда подчёркивает: соединяй учёбу с жизнью, связывай учёбу с жизнью. Только тогда учёбу можно назвать настоящей учёбой, а жизнь — настоящей жизнью.

Что касается трёхуровневой архитектуры, я долго думал, как связать её с реальной жизнью. Что ж, вчера вечером у меня внезапно появилось «озарение». Помните ли вы ещё историю из Big Talk Design Patterns о том, как Большая Птица и Сяо Цай едят шашлык из ягнёнка, — паттерн «Команда», вызванный едой на уличном лотке в отличие от еды в ресторане (конечно, сегодня мы изучаем не паттерн «Команда»). Официант, повар и закупщик.

Разве это не типичная трёхуровневая архитектура??? (⊙ o ⊙) Ах! Ха-ха (я объясню это позже)

Сначала давайте разберёмся:

1. Что такое трёхуровневая архитектура?

UI (уровень представления):В основном обозначает интерфейс, который взаимодействует с пользователем. Он используется для приёма данных, вводимых пользователем, и отображения обработанных данных, необходимых пользователю.

BLL (уровень бизнес-логики):Мост между слоем UI и слоем DAL. Он реализует бизнес-логику. К бизнес-логике относятся: проверка, вычисления, бизнес-правила и т. д.

DAL (уровень доступа к данным):Работает с базой данных. В основном реализует добавление, удаление, изменение и запрос данных. Он передаёт данные, хранящиеся в базе данных, бизнес-слою и одновременно сохраняет данные, обработанные бизнес-слоем, в базу данных. (Конечно, все эти операции основаны на слое UI. Потребности пользователя отражаются в интерфейсе (UI), UI передаёт их в BLL, BLL передаёт их в DAL, DAL выполняет операции с данными, а затем возвращает их одну за другой, пока нужные пользователю данные не будут переданы обратно пользователю.)

У каждого слоя есть свои обязанности, так как же должны быть связаны три слоя?

1. Однонаправленная ссылка (см. рисунок ниже)

2. На этом этапе подключается слой сущностей. (Примечание: конечно, роль слоя сущностей не ограничивается этим.)

Сущность:Она не принадлежит ни одному из трёх слоёв, но это необходимый слой.

Роль сущности в трёхуровневой архитектуре:

  • 1. Реализовать «инкапсуляцию» в объектно-ориентированном мышлении;
  • 2. Проходить через три слоя и передавать данные между ними; (Примечание: если быть точным, слой сущностей проходит через три слоя, чтобы соединить их.)
  • 3. Для начинающих это можно понять так: каждая таблица данных соответствует сущности, то есть поля в каждой таблице данных соответствуют свойствам в сущности. (Примечание: конечно, в действительности это не так. Почему? 1> Нужной нам сущности может не быть в сущности, соответствующей таблице данных; 2> Мы вполне можем поместить все поля из всех таблиц данных в одну сущность.)
  • 4. Передача данных (однонаправленная) между каждым слоем (UI—>BLL—>DAL) осуществляется с помощью переменных или сущностей в качестве параметров. Это создаёт связь между тремя слоями и завершает реализацию функциональности.

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

（Примечание:Почему здесь говорится, что можно временно понимать это так, что каждая таблица данных соответствует одной сущности? Ответ: Как всем известно, цель создания системы — предоставлять услуги пользователям. Пользователям всё равно, как работает бэкенд вашей системы; пользователей волнует только, удобно ли использовать программное обеспечение и пришёлся ли им по вкусу интерфейс. Когда пользователи легко выполняют добавление, удаление, изменение и запрос в интерфейсе, в базе данных также должны быть соответствующие операции добавления, удаления, изменения и запроса. Конкретными объектами операций добавления, удаления, изменения и запроса являются данные в базе данных, что, проще говоря, — поля в таблицах. Поэтому, если рассматривать каждую таблицу данных как класс сущности, а свойства, инкапсулированные классом сущности, соответствуют полям в таблице, то когда сущность проходит через все три слоя, она может реализовать добавление, удаление, изменение и запрос данных.)

В итоге: зависимости между тремя слоями и слоем Entity:

Идея взята из жизни:

Официант:Отвечает только за приём гостей;

Повар:Отвечает только за приготовление заказанных гостями блюд;

Закупщик:Отвечает только за закупку ингредиентов в соответствии с требованиями заказа гостей;

Каждый из них выполняет свои обязанности. Официанту не нужно знать, как готовит повар, и как закупщик закупает ингредиенты; повару не нужно знать, каких гостей обслужил официант, и как закупщик закупает ингредиенты; аналогично закупщику не нужно знать, каких гостей обслужил официант, и как готовит повар.

Как связаны эти трое?

Например: повар может приготовить: жареные баклажаны, яичницу-болтунью, чоу-мейн — на этом этапе создаются три метода (cookEggplant(), cookEgg(), cookNoodle())

Клиент взаимодействует напрямую с официантом. Клиент говорит официанту (слой UI): «Я хочу жареные баклажаны». Официант не отвечает за приготовление баклажанов, поэтому передаёт запрос наверх повару (слой BLL). Повару нужны баклажаны, поэтому он передаёт запрос наверх закупщику (слой DAL). Закупщик берёт баклажаны со склада и передаёт их обратно повару. Повар вызывает метод cookEggplant() и, приготовив жареные баклажаны, передаёт их обратно официанту, который подаёт баклажаны клиенту.

На этом завершается полная операция.

В этом процессе баклажан передаётся как параметр между тремя слоями. Если клиент заказывает яичницу-болтунью, то яйцо используется как параметр (это использование переменных в качестве параметров). Если пользователь добавляет требования, нам всё равно приходится добавлять параметры в методы — в один метод добавляется один параметр, а один метод затрагивает три слоя; кроме того, в реальности изменяется не только один метод. Поэтому, чтобы решить эту проблему, мы можем определить баклажан, яйцо и лапшу как свойства в сущности клиента. Как только клиент добавляет требование о яичнице-болтунье, мы можем напрямую извлечь свойство яйца и использовать его. Не нужно думать о добавлении параметров в методы каждого слоя и тем более беспокоиться о сопоставлении параметров.

Интересно, всем ли понятно это объяснение. (Позже объясню на примере.)

2. Зачем использовать трёхуровневую архитектуру?

Цель использования трёхуровневой архитектуры: снижение связанности!!!

Аналогично, возьмём пример с рестораном выше:

(1) Официант (уровень UI) уходит в отпуск — наймите другого официанта; шеф-повар (уровень BLL) увольняется — наймите другого шеф-повара; закупщик (DAL) увольняется — наймите другого закупщика; (2) Отзыв клиента:

  • 1. «В вашем ресторане плохо относятся к клиентам» — это проблема официанта. Увольте официанта;
  • 2. «В вашем блюде есть баг» — это проблема шеф-повара. Замените шеф-повара;

Любое изменение в одном слое не повлияет на другие слои!!!

3. В чём отличие от двухуровневой?

Двухуровневая:

(Когда меняется любая часть, всю систему нужно перерабатывать заново. «Множество слоёв» помещены в один слой, разделение труда неясно, а связанность высокая — из-за этого трудно адаптироваться к изменениям требований; низкая сопровождаемость и низкая масштабируемость.)

Трёхуровневая:

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

В итоге, преимущества трёхуровневой архитектуры:

  • 1. Чёткая структура и слабая связанность
  • 2. Высокая сопровождаемость, высокая масштабируемость
  • 3. Способствует синхронной разработке задач, легко адаптируется к изменениям требований

Преимущества и недостатки трёхуровневой архитектуры:

  • 1. Она снижает производительность системы. Это самоочевидно. Если не применять слоистую структуру, многие операции могут напрямую обращаться к базе данных для получения соответствующих данных, но теперь их нужно выполнять через средний слой.
  • 2. Иногда приводит к каскадным изменениям. Такие изменения особенно заметны при движении сверху вниз. Если на уровне представления нужно добавить функцию, чтобы её дизайн соответствовал слоистой структуре, возможно, потребуется добавить соответствующий код как на уровне бизнес-логики, так и на уровне доступа к данным.
  • 3. Она увеличивает объём кода и повышает трудозатраты.

4. Каковы конкретные формы трёх слоёв?

UI：

(Не поймите неправильно — слой UI — это не просто набор пользовательских интерфейсов; в нём также должен быть код.)

(1. Функция: пользователь вводит данные, данные возвращаются пользователю; 2. Все посмотрите на код: бизнес-логика не задействована, только прямая передача параметров, вызовы функций/методов, и нет SQL-запросов или ADO.NET для работы с базой данных.)

BLL：

(1. BLL — это мост между уровнем представления и уровнем доступа к данным, отвечающий за обработку и передачу данных; 2. Все обратите внимание на код: не задействованы элементы управления интерфейса, не используются SQL-инструкции или ADO.NET.)

DAL：

(1. Выше приведён код в классе DbUtil, классе user_DA и классе workRecord_DA на уровне DAL; 2. Все обратите внимание на код: не задействованы элементы управления интерфейса, не задействована бизнес-логика; только SQL-инструкции и ADO.NET для работы с базой данных.)

Уровень сущностей (Model):

(Определяет класс сущности user)

Рассмотрим вышеуказанные три уровня:

  • 1. Класс сущности user проходит через три уровня в качестве параметра;
  • 2. Функциональность реализуется через передачу параметров и вызовы методов;
  • 3. Каждый уровень отвечает за свои задачи и не влияет на остальные;

Сравните двухуровневую структуру, чтобы дать всем глубокое понимание огромных преимуществ трёхуровневой структуры:

По-прежнему используем в качестве примера вход в систему оплаты компьютерного класса:

(Посмотрите на двухуровневый код выше: и бизнес-логика, и доступ к данным представлены в слое представления пользователя. Когда требования должны измениться, приходится менять всю систему. Например, если я изменю имя текстового поля txtPassWord на txtPwd, вы увидите, сколько мест нужно изменить. Такое изменение считается небольшим. Если же произойдёт реальное изменение бизнес-требований, это будет поистине хлопотно и сложно. Было бы чудом, если бы программисты не прыгали с здания. Хе-хе... шучу.)

Исходный адрес: https://blog.csdn.net/hanxuemin12345/article/details/8544957/