WPF/Layered Architecture Question -

Question

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

Обычно я думаю, что с точки зрения этого

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Важное значение при разработке приложений - это возможность сменять вещи из неизменяемых.

HTH