SOA и MVC - когда использовать

Ответ 1

SOA - это намного больше, чем просто отправка JSON веб-клиенту.

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

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

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

В самом начале, то, что SOA на самом деле, принимает на себя этот сервер приложений (который может случиться с использованием json через http, но может также предлагать совершенно другой интерфейс или даже автоматически переводить между несколькими технологиями передачи данных) и обеспечивать соблюдение все, а не только некоторые, доступ к базе данных проходит через этот сервер приложений: сервисный уровень.

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

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

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

Вопрос о том, когда использовать JSON vs, когда использовать ASP.Net MVC, принимает новую форму. ASP.Net MVC может быть частью архитектуры SOA, а инфраструктура служб, предлагающая данные JSON, часто реализуется с использованием клиентских MVC-библиотек. Вы действительно хотите знать, когда более целесообразно делать больше на стороне клиента, а не на стороне сервера. Честно говоря, я думаю, что это в основном личные предпочтения, но есть компромиссы, о которых вы должны знать.

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

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

Ответ 2

Архитектуры MV * на стороне клиента MV * (MVC, MVP, MVVM и т.д.) и архитектуры MV * на стороне сервера совпадают с частью SOA вашей архитектуры.

Модель - это то, где вы общаетесь со службами и извлекаете данные из различных служб. Выбор между клиентской стороной MV * и стороной сервера ортогонален.