WPF / Вопрос многоуровневой архитектуры -

Question

Я думаю о высокоуровневой архитектуре приложения WPF.

Обычно я думаю об этом

• Сервер базы данных
• AУровень доступа к данным на своем собственном сервере
• Уровень бизнес-логики на своем собственном сервере
• Оболочка WCF для бизнес-уровня
• Уровень пользовательского интерфейса для использования на клиенте.

Например, тонкий клиент со всей магией, происходящей на удаленных серверах.

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

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

Мой вопрос ... есть ли какие-либо веские архитектурные причины НЕ развертывать уровень бизнес-логики дляклиентские машины вместе со слоем пользовательского интерфейса, когда веб-сервисы не требуются?

Я могу думать о drwabacks, но ни один из них не кажется настолько большим

• Меньше необходимости обновлений на клиенте (но, конечно, clickonce уменьшает это)
• Больше нагрузки на клиентский компьютер.
• Необходимо убедиться, что сервер базы данных достаточно громоздкий и соединение с ним достаточно большое

Answer 1

Обычно я бы отделил бизнес-логику от пользовательского интерфейса.Зачем ?Потому что ваш пользовательский интерфейс может быть только один клиент этой службы.

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

Обычно я делаю бизнес-логику компонентом, а затем могу выбрать, как ее развернуть (на клиенте илисервер).Однако во многих случаях я не могу этого сделать.например, если клиент и сервер реализованы с использованием разных технологий (C # / Java является общей комбинацией).

Answer 2

Ну, я тоже полностью согласен с Брайаном и Бертом. «Разные клиенты, использующие разные версии бизнес-логики», действительно имеют смысл.

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

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

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

НТН

Answer 3

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

ТакжеЕсли подумать о развертывании, развертывание на 1 сервере будет проще, чем на всех клиентах.Каковы шансы того, что разные клиенты используют разные версии бизнес-логики?