Следует ли использовать Rich Client Arch в многоуровневых корпоративных системах

Question

У нас достаточно крупное корпоративное, многоуровневое, многоуровневое решение, построенное на .Net 3.5. Система представляет собой сервис-ориентированную архитектуру (службы WCF) с интерфейсом пользователя ASP.Net MVC, стоящим перед ней.

Некоторые ребята из команды работают над инструментарием для системы и реализуют их как архитектуры богатых клиентов WPF, которые подключаются напрямую к базе данных (или другим источникам данных).

Почему-то мне это не подходит по следующим причинам:

1. Для этого потребуется, чтобы SQL Server был доступен для нескольких машин (на которых запущены инструменты) напрямую. Разве не рекомендуется когда-либо разрешать вашему уровню приложений подключаться к уровню базы данных? Сквозная аутентификация в любом случае будет использоваться для обеспечения возможности аудита, поэтому не возникает проблем с управлением несколькими учетными записями.
2. Дублирование (или, по крайней мере, распространение) бизнес-логики должно произойти. Вместо того, чтобы размещать бизнес-логику на сервере для повторного использования, он должен располагаться на каждой клиентской машине.
3. Обслуживание нескольких клиентских установок: теперь все эти машины должны обновляться отдельно каждый раз, когда выпускается новая версия инструмента. Хорошо, вы все равно можете использовать что-то вроде одного щелчка, чтобы автоматически обновлять его.

и т. Д. И т. П.

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

Я понимаю, как использовать Rich Clients для таких приложений, как word или excel, но если у вас уже есть законченное многоуровневое решение, то, конечно, это не лучший способ сделать это?!?

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

Что ты думаешь? Что вы, ребята, испытали в прошлом? Где я могу найти ресурсы, чтобы доказать или опровергнуть мои пункты выше?

---

См. Также: Google Планета Земля - ​​Богатый клиент или богатая интернет-архитектура?

Answer 1

Если у вас есть сервисный уровень с какой-либо существенной логикой, то я чувствую, что довольно опасно обходить это, переходя непосредственно от RIA UI к базе данных.

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

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

Я добился значительного успеха в разработке многократно используемых сервисов на уровне сервисов, к которым можно получить доступ из нескольких различных реализаций пользовательского интерфейса. Мне очень приятно, что сервис RIA + - это хороший, масштабируемый архитектурный шаблон.

Answer 2

Для всех более новых систем у нас есть клиентский уровень, который взаимодействует с сервисным уровнем, который, в свою очередь, обращается к базе данных.

_{(источник: msdn.com )}

Если вы используете технологию Microsoft, для ее реализации доступны службы .Net RIA:

http://blogs.msdn.com/brada/archive/2009/03/19/what-is-net-ria-services.aspx

Answer 3

Да, они могут / должны быть использованы! . Чтобы прокомментировать ваши причины:

1. Нет, это была первоначальная роль SQL сервер. Несколько приложений подключение к той же базе данных. Это было очень распространено в 90-х годах с Интранет, где несколько автономных приложения использовали один и тот же дБ. Базы данных поддержать это очень хорошо, и это причина, по которой у них так много степень безопасности для пользователя счета (а также просмотры, ограничения e.t.c). Единственное приложение Сервер разговаривает с БД "новее шаблон начался в последние 9-10 лет
2. Да, вы правы. Рекомендуемый способ решить это то, что автономно клиенты бьют по бизнес логике компоненты серверного приложения а не БД напрямую. Я не знать о .NET, но в J2EE это будет означать удар по EJB или использование RMI / Web-сервисы. Таким образом, код бизнес-логики существует только один раз (на сервере).
3. Опять вы правы, но снова это разрешима В мире J2EE это решается с помощью Java Web Start, поэтому я угадайте, что нечто подобное работает в .NET.

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