Что n-tier значит для Вас?

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

Как пример мы раньше имели то, что я назову 3 системы уровня (дб, dll, страницы ASP) работой единственного сервера. По некоторым определениям это - единственная система уровня. У нас теперь есть база данных, работающая на отдельном сервере, единственное требуемое изменение было строкой подключения, но теперь это будет двумя решениями для уровня?

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

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

Касательно.

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

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

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

Но думая много позже чтения других ответов я соглашаюсь с Garry на этом.

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

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

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

я согласился бы с Garry Shutler, но добавил бы, что много уровней могли бы также существовать в единственном процессе/потоке или даже том же блоке. более важный, чем медосмотр (аппаратные средства, исполняемая изоляция или двоичная изоляция) разделение является расположением кода для разработчика (по моему скромному мнению). как в с aspnet приложением: у того же dll могли быть все три уровня в нем: доступ к данным, домен и презентация.

Посмотрите на историю термина "уровень" в вычислениях. Никакие упомянутые 1-уровневые вычисления на desktops/minis/mainframes. Никакие упомянутые 2-уровневые вычисления в течение дней клиент-сервер. 3-уровневый стал архитектурным моникером для клиент-сервер плюс промежуточное промежуточное программное обеспечение (сообщение, ориентированное на промежуточное программное обеспечение и брокеров транзакции). Я думаю, что n-tier был популяризирован наряду с другим термином "EAI - или Интеграция Архитектуры предприятия". Это была точно та же идея, как архитектура для обслуживания широкого круга запросов, кроме большинства реализаций поставщика были или собственными, базирующиеся стандарты, но очень дорогими, или оба. После XML-RPC приходят SOAP и REST, они называют его "веб-сервисами" и затем применяют принцип EAI позади него и подходят к SOA - Сервис-ориентированная архитектура и Сервисная шина предприятия.

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