Что для вас значит n-уровень?

Question

За прошедшие годы я заметил, что разные разработчики имеют разные критерии для того, что составляет уровень в разработке n-уровневой системы, поэтому мне было любопытно, какой консенсус здесь в stackoverflow.

Достаточно ли отдельных логических уровней, чтобы называть его отдельным уровнем, или его необходимо развернуть на отдельном сервере (физическом или виртуальном), чтобы называть его отдельным уровнем?

Позвольте мне сформулировать вопрос немного по-другому. Если механизм вызова может быть только в процессе, локальном потоке или локальном квартире, то можно ли утверждать, что это два разных уровня в зависимости от того, как классы организованы в библиотеки или пакеты?

Answer 1

Мне достаточно отдельного логического слоя, чтобы назвать его уровнем. Это не обязательно должно быть на отдельном сервере, но определенное разделение с другими уровнями, безусловно, делает это возможным.

В качестве примера у нас была так называемая трехуровневая система (страницы db, dll, asp), работающая на одном сервере. По некоторым определениям это одноуровневая система. Теперь у нас есть база данных, работающая на отдельном сервере, единственное требуемое изменение - это строка подключения, но теперь это будет двухуровневое решение?

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

Answer 2

Для меня физический уровень означает часть системы, предназначенную для для работы на другой физической машине. Да, вы можете в любое время указать строку подключения к БД на другом сервере, но если ваш DAL слишком болтлив, имеет n + 1 и проблемы с неограниченным набором записей, сетевая задержка убьет вас очень быстро.

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

Answer 3

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

Ref .

Answer 4

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

Подавляющее большинство веб-приложений по умолчанию имеют 3 уровня (браузер, веб-сервер, сервер базы данных). Большинство интранет-приложений являются двухуровневыми (клиент, сервер БД). Но в любом случае я создаю уровень пользовательского интерфейса, бизнес-уровень и уровень данных. Они разделяют интересы и помогают мне структурировать мой код для удобства обслуживания. Также в любом случае я обычно заканчиваю тем, что развернул их все на одной коробке; веб-сервер или клиентская рабочая станция. Таким образом, слои и уровни даже не совпадают.

Answer 5

Посмотрите на историю термина "уровень" в вычислительной технике. Никто не сказал, одноуровневые вычисления на десктопах / мини / мэйнфреймах. Никто не говорил о двухуровневых вычислениях в дни клиент-сервер. Трехуровневый стал архитектурным прозвищем для промежуточного ПО клиент-сервер плюс промежуточное ПО (промежуточное ПО, ориентированное на сообщения и посредники транзакций). Я думаю, что n-уровень был популяризирован вместе с другим термином «EAI - или интеграция архитектуры предприятия». Это была та же идея, что и для сервис-ориентированных архитектур, за исключением того, что большинство реализаций поставщиков были либо проприетарными, основанными на стандартах, но очень дорогими, либо и тем, и другим. После появления XML-RPC, SOAP и REST они называют его «веб-сервисами», а затем применяют принцип EAI и переходят к SOA - сервис-ориентированная архитектура и корпоративная сервисная шина.

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

Answer 6

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

Итак, ответьте на вопрос / комментарий. Если в вашей базе данных есть куча логики (бизнес или иным образом) в хранимых процедурах, следует ли это также рассматривать как уровень? Что, если вы используете функции вашего механизма базы данных, такие как Service Broker для Microsoft SQL Server? Это можно рассматривать как наличие двух уровней.

Кроме того, фоновые сервисы и / или демоны, это отдельный уровень и / или слой или они принадлежат существующему?

Answer 7

Я согласен с Гарри Шатлером, но добавлю, что многие уровни могут также существовать в одном процессе / потоке или даже в одной сборке. более важным, чем физическое (аппаратное, исполняемое или двоичное) разделение, является компоновка кода для разработчика (IMHO). как в случае приложения aspnet: одна и та же библиотека DLL может содержать все три уровня: доступ к данным, домен и представление.

Answer 8

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

Но, подумав хорошо после прочтения других ответов, я согласен с Гарри на , что .