WPF / многоуровневая архитектура вопрос -
Я думаю о высокоуровневой архитектуре приложения WPF.
Обычно я думаю в терминах этого
- сервер баз данных
- уровень доступа к данным на собственном сервере
- уровень бизнес-логики на собственном сервере
- WCF-оболочка вокруг бизнес-слоя
- слой пользовательского интерфейса для использования на клиенте.
Например, тонкий клиент со всем волшебством, происходящим на удаленных серверах.
Но кто-то из команды задался вопросом, есть ли уровень бизнес-логики должен находиться на удаленном сервере. Почему бы просто не перенести это на клиент, сделав его менее тонким клиентом и более толстым клиент-серверным приложением.
На данный момент нам не нужен WCF, и если предположить, что мы все еще создаем бизнес-логику, так что она находится на отдельном уровне, это имеет некоторый смысл для меня с точки зрения упрощения инфраструктуры.
Вот мой вопрос... есть ли какие-либо веские архитектурные причины не разворачивать бизнес-логику слой к клиентским машинам вместе со слоем пользовательского интерфейса, когда веб-сервисы не требуются?
Я могу думать о drwabacks, но ни один из них не кажется таким большим
- меньше необходимости в обновлениях на клиенте (но, конечно, clickonce смягчает это)
- больше нагрузки на клиентскую машину.
- Необходимо убедиться, что сервер базы данных достаточно коренаст и подключение к нему достаточно большое
3 ответов:
Обычно я отделяю бизнес-логику от пользовательского интерфейса. Почему? Потому что ваш пользовательский интерфейс может быть только одним клиентом этой службы.
На данный момент ваш клиент является единственным потребителем этой услуги, но на более позднем этапе вы можете пожелать иметь дополнительных клиентов (включая другие услуги), использующих ее. Выделив бизнес-логику, вы можете сделать ее доступной для других потребителей.Обычно я делаю бизнес-логику компонентом, а затем могу выбрать, как это сделать. разверните его (в клиенте или на сервере). Однако во многих случаях я не могу этого сделать. например, если клиент и сервер реализованы с использованием различных технологий (C#/Java является общей комбинацией).
Полностью согласен с Брайаном. Обычно я проектирую веб-сервисы от клиента до бизнес-логики на отдельном сервере, это делает его расширяемым, но все зависит от того, насколько надежной должна быть система.
Также подумайте о развертывании, было бы проще развернуть на 1 сервер, чем развернуть на всех клиентах. Какова вероятность того, что разные клиенты используют разные версии бизнес-логики?
Ну, я тоже полностью согласен с Брайаном и Бертом. "Разные клиенты, работающие с разными версиями бизнес-логики" - это действительно имеет смысл.
В принципе, разделение по проблемам (SoC) является наиболее важным моментом, позволяющим любому приложению масштабироваться достаточно для расширения его для будущих потребностей. Как архитектура вы должны по крайней мере воспринять это и построить некоторые основные работы.
Большинство современных приложений не являются монолитными и не остаются неизменными. Бизнес-требования таковы: измененные так быстро, следовательно, они будут нуждаться в изменениях в приложении тоже.Разделение изменяемых вещей от неизменяемых важно при разработке приложений, чтобы позволить легко расширить их.
HTH
Comments