Что для вас значит n-уровень?
За прошедшие годы я заметил, что разные разработчики имеют разные критерии для того, что составляет уровень в разработке n-уровневой системы, поэтому мне было любопытно, что такое консенсус здесь, в stackru.
Достаточно ли отдельных логических уровней, чтобы называть его отдельным уровнем, или его необходимо развернуть на отдельном сервере (физическом или виртуальном), чтобы называть его отдельным уровнем?
Позвольте мне сформулировать вопрос немного по-другому. Если механизм вызова может быть только в процессе, локальном потоке или локальном квартире, то можно ли утверждать, что это два разных уровня в зависимости от того, как классы организованы в библиотеки или пакеты?
8 ответов
Для меня физический уровень означает часть системы, предназначенную для работы на другой физической машине. Да, вы можете в любое время указать строку подключения к БД на другом сервере, но если ваш DAL слишком болтлив, имеет n+1 и проблемы с неограниченным набором записей, сетевая задержка убьет вас очень быстро.
С другой стороны, логический уровень поддерживает преимущества разделения интересов, сплоченности и связи. Строго говоря, он даже не должен находиться в отдельной сборке - пространство имен сработает. Только не звоните в те классы, о которых вы не знаете, NDepend поможет вам.
Мне достаточно отдельного логического слоя, чтобы назвать его уровнем. Это не обязательно должно быть на отдельном сервере, но определенное разделение с другими уровнями, безусловно, делает это возможным.
В качестве примера у нас была так называемая трехуровневая система (страницы db, dll, asp), работающая на одном сервере. По некоторым определениям это одноуровневая система. Теперь у нас есть база данных, работающая на отдельном сервере, единственное требуемое изменение - это строка подключения, но теперь это будет двухуровневое решение?
Вот почему я считаю, что концепция уровня больше связана с возможностью запуска их на отдельных машинах, а не с необходимостью. Это кажется мне более последовательным.
Понятия уровня и уровня часто используются взаимозаменяемо. Однако одна довольно распространенная точка зрения заключается в том, что разница действительно существует и что уровень представляет собой механизм логического структурирования для элементов, составляющих программное решение, а уровень - это механизм физического структурирования для инфраструктуры системы.
Слои представляют собой механизм минимизации сцепления; они логичны. Уровни разработаны, чтобы максимизировать производительность или минимизировать риски безопасности; они физические. Они действительно не такие же, и я не уверен, почему люди пытаются использовать их взаимозаменяемо.
Подавляющее большинство веб-приложений по умолчанию являются трехуровневыми (браузер, веб-сервер, сервер базы данных). Большинство приложений для интрасети являются двухуровневыми (клиент, сервер БД). Но в любом случае я создаю уровень пользовательского интерфейса, бизнес-уровень и уровень данных. Они разделяют интересы и помогают мне структурировать мой код для удобства обслуживания. Кроме того, в любом случае я обычно заканчиваю развертывание их всех на одной коробке; веб-сервер или клиентская рабочая станция. Таким образом, слои и уровни даже не совпадают.
Я должен сказать, что определения должны быть выработаны. Обычно я рассматриваю уровень как логическое разделение функциональности и ответственности, а уровень как требование или способность к физическому разделению. Некоторые слои могут иметь несколько уровней, а некоторые уровни могут охватывать слои. Обычно я использую уровень сервисного уровня, который может обеспечить физическое разделение, если это необходимо и / или желательно с помощью конфигурации.
Итак, ответьте на вопрос / комментарий. Если в вашей базе данных есть куча логики (бизнес или иным образом) в хранимых процедурах, следует ли это также рассматривать как уровень? Что, если вы используете функции своего механизма базы данных, такие как Service Broker для Microsoft SQL Server? Это можно рассматривать как наличие двух уровней.
Кроме того, фоновые сервисы и / или демоны, являются ли они отдельным уровнем и / или уровнем или они принадлежат существующему?
Я согласен с Гарри Шатлером, но добавлю, что многие уровни могут также существовать в одном процессе / потоке или даже в одной сборке. более важным, чем физическое разделение (аппаратное обеспечение, изоляция исполняемого файла или двоичная изоляция), является компоновка кода для разработчика (IMHO). как в случае приложения aspnet: одна и та же библиотека DLL может содержать все три уровня: доступ к данным, домен и представление.
Посмотрите на историю термина "уровень" в вычислительной технике. Никто не сказал, одноуровневые вычисления на десктопах / мини / мэйнфреймах. Никто не говорил о двухуровневых вычислениях в дни клиент-сервер. Трехуровневый стал архитектурным прозвищем для промежуточного ПО клиент-сервер плюс промежуточное ПО (промежуточное ПО, ориентированное на сообщения и посредники транзакций). Я думаю, что n-уровень был популяризирован вместе с другим термином "EAI - или интеграция архитектуры предприятия". Это была та же идея, что и у сервис-ориентированных архитектур, за исключением того, что большинство реализаций поставщиков были либо проприетарными, основанными на стандартах, но очень дорогими, либо и тем, и другим. После появления XML-RPC, SOAP и REST они называют его "веб-сервисами", а затем применяют принцип EAI и переходят к SOA - сервис-ориентированная архитектура и корпоративная сервисная шина.
Я хочу сказать, что ни один из этих терминов не подразумевал какого-либо физического разделения... оно всегда было связано с логическим разделением функций. Так уж сложилось, что многие из этих логических прикладных уровней были спроектированы так, чтобы не иметь состояния, чтобы они могли физически разделяться для горизонтальной масштабируемости.