Какова моя архитектура?

Question

Меня попросили определить архитектуру моего приложения, но я немного расстроен тем, как это сформулировать. Что вы, ребята, думаете?

• Мы разработали приложение .Net MVC.
• Используется внутри локальной сети.
• У нас есть рабочие станции, которые просматривают веб-сайт MVC (уровень представления)
• У нас есть сервер приложений, на котором размещен сайт (логический уровень)
• У нас есть сервер базы данных, на котором хранятся данные (SQL 2008 R2) (Уровень данных)

Так что я подумал, что из-за уровней это трехуровневая архитектура.
Однако, поскольку мы использовали MVC, означает ли это, что наши слои более непосредственно (хотя и слабо связаны) связаны, что делает нашу архитектуру менее линейной (трехуровневой) и более треугольной (MVC)?

Как вы думаете, я должен описать эту архитектуру?

Answer 1

Я думаю, что термин «3-уровневая архитектура» является плохо определенным и устаревшим, поскольку он подчеркивает не то, как ваш код структурирован, и не дает никаких преимуществ или недостатков с точки зрения пользователя.Проблема в том, что оно относится к физическому развертыванию , что во времена виртуализации и распределенных вычислений вряд ли имеет смысл.

«Уровень» относится к машинам , иПоскольку вы, как правило, можете запускать и отлаживать свой веб-сайт только с помощью локальной машины разработчика, его обычно можно развернуть на 1 уровне.Возможно, более актуальным вопросом является «каково максимальное количество (логических) машин, на которые я могу разбить мое приложение?» Это число не зависит от фактического фактического развертывания , ивместо этого диктуется структура кода - наслоение.Конечно, машины, которые дублируют другую машину (несколько веб-серверов для балансировки нагрузки), не учитываются.

Информация по-прежнему вряд ли актуальна.Предполагается, что ваш код разделяет проблемы и может быть более масштабируемым, чем код, который не позволяет разбивать на отдельные уровни.Другая идея - сильная развязка: вы можете заменить один слой, не касаясь другого.На практике это вряд ли когда-либо работает (например, переключение с Oracle на MySQL) и решает некоторые устаревшие проблемы: «изменение операционной системы на уровне представления повлияет только на код пользовательского интерфейса».( Wikipedia )

Все это становится более нечетким, когда вы добавляете внешние продукты SaaS / PaaS или сторонние инструменты, такие как SolR (поисковая система).Является ли SolR частью уровня данных или частью логического уровня?Становится ли ваша архитектура четырехуровневой, добавляя слой кэширования?Что если ваш уровень базы данных - это не одна машина, а кластер из 10 машин?

MVC, с другой стороны, относится к структуре вашего кода.Однако это не только шаблон уровня представления: модель не знает ни контроллера, ни представления.MVC разделяет данные, представление и логику на различные слои .Большинство реализаций MVC используют Two-Step-View в качестве шаблона уровня представления и PageController в качестве шаблона контроллера. FrontController обычно также существует и обрабатывает все запросы перед делегированием соответствующему PageController - но главное, что модель не знает всего этого.

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

Answer 2

Я бы описал его как трехуровневое приложение и поместил бы аспект MVC в уровень представления.

Поскольку ваша базовая структура является трехуровневой и использует MVC для отображения данных пользователю. (Может быть, вы можете поставить флажок с наложением MVC на уровень представления и уровень приложения - чтобы проиллюстрировать фактическое взаимодействие между этими двумя).