Вопрос

Я только что встретил следующую фразу:

По мере того, как отрасль перешла от трехуровневой модели к моделям N-уровня, несоответствие импеданса объекта стало более распространенным.

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

Это было полезно?

Решение

Похоже, что цитата взята с этой codeproject страницы. Похоже, что он неплохо объясняет, что n-уровень включает такие вещи, как веб-сервисы, javascript, рабочие процессы и т. Д. Все вещи, которые не обязательно включают в себя 3-уровневые модели.

Другие советы

В процессе разработки мы понимаем уровень как " уровень ответственности " абстракция.

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

В этом смысле так называемая трехуровневая модель или n-уровневые модели являются просто различными реализациями этих концепций.

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

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

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

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

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

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

Обратите внимание, что, кроме того, n-уровневая архитектура позволяет распределять эти & обязанности " среди разработчиков. Таким образом, данная группа может нести ответственность за уровень абстракции базы данных, в то время как другая группа работает на уровне прокси, а другая - на уровне абстракции графики. Когда член команды должен получить доступ к базе данных, он просматривает документацию DAL и использует одно из предоставленных средств или просит группу DAL предоставить необходимую ему функциональность, чтобы он не обращался непосредственно к базе данных, а через людей, которые лучше знают дизайн и тонкости самой базы данных.

Если бы мы смотрели на ярусы как на слои торта; каждый слой будет иметь свои ингредиенты и делать свои дела.Уровни каждого приложения взаимодействуют только с уровнем выше или ниже него.

Трехъярусный означает, что торт состоит из трех слоев.Обычно это данные внизу, затем уровень логики приложения (PHP/ruby/и т. д.), а затем уровень представления вверху (html).

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

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

Обычно я получаю пятиуровневое приложение.Каждый уровень может взаимодействовать только с уровнем выше или ниже него.Это может обеспечить фантастическую расширяемость и стандартизацию вашего приложения.

Клиентский уровень

Веб-браузер


Уровень презентации

Рендеринг HTML — Coldfusion/Flash/Ruby/PHP и т. д.


Уровень бизнес-логики

Запускайте процессы и вычисления по мере необходимости — Coldfusion/Flash/Ruby/PHP и т. д.


Уровень интеграции данных

(Запросы из моего языка разработки, хранимых процедур и т. д.)


Уровень данных

(База данных – MySQL и т. д.)

n-уровень подразумевает, что n - это любое число - когда n = 3, то это то же самое, что и n-уровень.

Обычное определение 3-уровня - это представление, логика & amp; данные (в любом порядке), и да, SOA может сбить с толку неофита, потому что иногда он находится на уровне данных, иногда на уровне логики, а иногда и на логике & amp; уровни данных.

Весь предмет ... субъективен. Если вам нужны некоторые уровни, тогда назовите их n-уровневым - если вы знаете, что n = 7, тогда назовите его 7-уровневым или n-уровневым.

Эй, я даже не могу получить определение 3 уровня. Иногда они игнорируют javascript на клиенте, а иногда javascript на клиенте и клиентском веб-браузере считаются другим уровнем. Таким образом, страница ASP, которая взаимодействует с базой данных, может быть трехуровневой, если вы предполагаете, что база данных = уровень 3, веб-сервер = уровень 2, клиентский веб-браузер = уровень 1. А в других случаях веб-сервер = уровень 1, промежуточное программное обеспечение = уровень 2, база данных = Уровень 3. Это действительно зависит от того, кто пишет определение / книгу.

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

Откуда эта цитата? К какой отрасли они относятся? Мне бы пришлось представить, что это как-то связано с SOA , потому что это единственный вещь, которая имеет смысл для такого рода заявлений.

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

Привет, пожалуйста, проверьте эту ссылку, чтобы вы могли получить хорошее представление об этом

http://msdn.microsoft.com/en-us/library /ms973829.aspx

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

Не рассматривая предложение в контексте, я предполагаю, что оно относится к взрыву в службах и промежуточном программном обеспечении.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top