3-уровневая архитектура против 2-уровневой архитектуры

Question

В каких примерах нам действительно нужна 3-уровневая архитектура? Может ли большинство приложений, использующих 3-уровневую архитектуру, быть выполнено с использованием 2-уровневой архитектуры?

Примечание: Я пытаюсь увидеть значение 3-уровневой архитектуры, я чувствую, что большинство приложений, которые сейчас имеют 3-х уровневые, могут быть выполнены в 2-х уровневых, поэтому я ищу примеры абсолютно необходимо 3 уровня, и нет никаких исключений из этой потребности.

Answer 1

Я предполагаю, что вы имеете в виду слоистые (логические единицы разделения), а не многоуровневые (физические единицы разделения / развертывания). Примером многоуровневой системы может служить веб-сервер (1 уровень), доставляющий веб-страницы (еще один уровень), который использует данные из базы данных 3-го уровня).

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

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

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

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

Answer 2

Переходит к FinnNk, но позвольте мне привести вам пример того, что происходит, когда вы не разделяете свои уровни. Я работал в течение многих лет над проектом, который был плохо разделен при рождении. Все три уровня - больше, если вы верите тому, что сказал Туинстул - объединены в отдельные страницы JSP. Я уверен, что в то время это казалось умным делом (быстрее кодировать, когда вы только начинаете), но это чудовище росло и росло, и никто не нашел времени на рефакторинг.

Теперь у нас более 2000 страниц JSP с дублирующимся кодом, разбросанным по всему. Внесение изменений в схему требует тщательного отслеживания, чтобы выяснить, какие страницы могут быть затронуты, и индивидуального тестирования каждой из этих страниц. Никто в управлении не считает, что достаточно важно тратить время на то, чтобы это исправить - краткосрочные выгоды, долгосрочные убытки.

У. Не. Идти. Это. Маршрут.

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

Answer 3

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

См. Например: http://www.infoq.com/news/2010/06/couchdb

"Хорошо ведет себя интерфейс HTTP / REST и API чистый и простой двухуровневый приложения (HTML + JavaScript в браузер + диван + javascript как сервер) "

Oracle имеет веб-сервер внутри, вы можете использовать хранимые процедуры, которые также предоставляют интерфейс отдыха для внешнего мира. Таким образом, JavaScript в вашем браузере также может вызывать базу данных Oracle без промежуточного уровня.

Вам всегда нужен средний уровень, когда все, что вам нужно, это получить данные из базы данных? Я сомневаюсь, что нужно.

(ТТТ, ранее известный как Tuinstoel)

Answer 4

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

1. Безопасность: отделяя свою бизнес-логику от представления, вы можете применять более строгие политики к различным уровням, например, формы презентации без данных или логики могут находиться в вашей зоне представления, чтобы анонимные пользователи могли получить доступ к вашему «общедоступному» контенту.
2. ремонтопригодность / управляемость - об этом уже много говорилось
3. Повторное использование / Аварийное восстановление: На практике, если приложение управления фарамией может захотеть предоставить пользовательский интерфейс, а также сервисы, которые могут использовать третьи стороны для размещения заказов на рецептурные препараты. Разделив бизнес-логику на отдельный уровень, вы можете поддерживать службы / логику независимо от пользовательского интерфейса

Есть несколько других, но мы надеемся, что они дают представление о потенциальных выгодах

Answer 5

В некоторых случаях вы можете перейти с 2-го уровня на 3-й: 1- Ваша система имеет другой тип клиентов (рабочий стол, Интернет, мобильный и т. Д.) 2- Ваша система имеет гетерогенный тип источников данных (например, ресурсы, не относящиеся к БД)
3 - вашей системе требуется определенный протокол связи клиент / сервер 4- Вы хотите скрыть и защитить уровень данных от клиента 5. Вам нужна масштабируемость по кластерам серверов и балансировке нагрузки. 6. Вам нужна интеграция между серверами, которая прозрачна для клиента 7- Вы хотите использовать общие ресурсы для количества клиентов (например, соединение с БД) 8. Вы хотите упростить обслуживание системы, отсоединив клиента от сервера базы данных или группы серверов 9- Вы хотите поместить бизнес-логику в отдельный уровень на конкретной платформе 10- Вы хотите уменьшить трафик между клиентом и БД

Answer 6

Что ж, если у вас есть веб-сайт ... Возможно, у вас есть некоторый код Javascript, так что когда-то это был уровень, у вас есть бизнес-логика на сервере и у вас есть база данных для хранения вещей. Это три уровня, на мой взгляд. Конечно, вы можете использовать хранимые процедуры в базе данных и пропустить уровень бизнес-логики, чтобы можно было создать веб-сайт с двумя уровнями, если вы хотите, но если вы не хотите использовать хранимые процедуры, у вас будет три уровня.