Довольно странная архитектура.
Вы действительно можете использовать SOA. Он имеет много преимуществ и хорошо изучен и поддерживается.
Однако я бы не использовал SOA для слоя презентации (и я не помню, чтобы это никогда не видел).
Обычно вы должны иметь бизнес-логику в слое и показывать ее как веб-службы (это SOA) и всю презентацию (в этом случае создавать модели просмотра MVC и возвращать визуализированные представления в браузер) в то же приложение. (См. Примечание внизу)
Нет смысла разделять презентацию на уровне SOA, потому что вы не можете повторно использовать ее ни для чего другого. То есть вы не можете использовать этот уровень представления для приложения Windows или использовать его для веб-приложения java.
Однако, если ваша бизнес-логика раскрывается на уровне SOA, вы можете использовать ее с любым пользовательским интерфейсом, который вы хотите: формы Windows, WPF или даже веб-приложение Java.
Помимо этого, существует несколько узлов между маршрутами и контроллерами в MVC. Вы не можете легко добиться того, что хотите. Однако вы можете легко создать уровень представления MVC (маршруты, контроллеры и viewws), который использует бизнес-уровень, открытый как SOA с ваших контроллеров. Это гораздо более естественно.
Возможно ли: конечно, но нестандартный и har to сделать.
Стоит ли: нет. Ваш canot повторно использовать его с другой techonlogy. В чем преимущество?
Есть что-то вроде этого: neve видел это!
ПРИМЕЧАНИЕ: наличие одного приложения не означает наличие одного слоя. Но вам не нужно отделять их в разных приложениях или слоях SOA. Если вы правильно используете MVC, у вас будет очень четкое разделение между представлениями (которые отображают результат для браузера) и контроллерами (которые готовят модели просмотра для рендеринга Views) и бизнес-уровня (который может быть в другом приложении, выставленные как сервисы SOA и потребляемые с этих контроллеров). Фактически, вряд ли невозможно плохо использовать MVC, если учесть, что вам нужны модели просмотра, которые являются объектами, специально созданными для визуализируемого представления, вместо прямого использования бизнес-объектов.
Например, модель vie может иметь данные клиента для ее редактирования, но, вероятно, будет иметь несколько списков вариантов для заполнения выпадающих списков. Если вы не используете модели просмотра, у вас скоро появятся проблемы.
Мы легко использовали такой подход для наших приложений с несколькими устройствами, в основном для управления смешением устройств. Он очень сложный (поскольку для каждого типа целевой презентации требуется дополнительный слой «разбора». Обратите внимание на Unity для более популярного примера. – Bora
Я думаю, что ваше решение слишком велико. Обычно вы можете обрабатывать несколько устройств с помощью маршрутов и, если абсолютно необходимые, специальные механизмы просмотра. В большинстве случаев это не обязательно. Во всяком случае, действительно ли вы используете разные приложения для обработки похожих представлений для разных устройств? Было бы проще сделать это в одном приложении? используя несколько приложений, каждое изменение в слое презентации требует изменения нескольких приложений. Дополнительное бремя! То, что вы используете это, не означает, что это лучшее решение. Вы уверены, что ваше ** действительно ** нуждается в этом сложном решении, и это дает вам добавленная стоимость? – JotaBe