Физическое разделение среднего уровня для приложений Windows Forms

Question

В последнее время я разрабатывал довольно много приложений для Windows Forms (приложения для ввода данных, интеграция офисов и т. Д.), И хотя я всегда проектировал с учетом логических уровней, уровень бизнес-логики «среднего уровня» всегда размещены на настольном ПК (т. е. физический клиент-сервер).

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

Мне любопытно узнать, как далеко продвинулись другие разработчики WinForms на среднем уровне:

• Сколько обработки (если есть) вы выполняете на сервере среднего уровня?
• Какой метод связи вы используете - WCF, удаленное взаимодействие, веб-сервисы и т. Д.?
• Насколько сильно влияет производительность, и как часто вы обращаетесь к серверу туда и обратно?

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

В качестве альтернативы, следует ли мне полностью отвлекать клиентов от WinForms, если в них вовлечены эти факторы? С альтернативами, такими как Silverlight и даже ASP.NET с AJAX, причины выбора клиента WinForms, похоже, сокращаются.

Answer 1

Важно помнить, что между простотой разработки и отдельным средним уровнем и всеми преимуществами масштабируемости и т. Д. Существует компромисс: что я имею в виду, так это то, что вам необходимо обновить сопоставления интерфейса и т. Д. в вашем коде вы должны развернуть средний уровень где-нибудь для использования вашими тестерами, который должен быть обновлен и т. д. Кроме того, если вы ленивы, как я, и передаете свои объекты Entity Framework напрямую, вы не можете сериализовать их на средний уровень поэтому вам нужно создать DTO для всех ваших операций и т. д.

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

Моя предпочтительная тактика - поддерживать физическое разделение с точки зрения сборок (т. Е. У меня отдельная сборка бизнес-логики / доступа к данным) и направлять все вызовы на бизнес-уровень через уровень интерфейса, который представляет собой связку Facade. классы. Так что все эти сборки находятся в моем приложении для Windows. Я также создаю интерфейсы для всех этих фасадов и получаю к ним доступ через фабрику.

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

Answer 2

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

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

Answer 3

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

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

Если у вас разные клиенты (личные данные), вы не получите большой выгоды от обработки на среднем уровне.