Должен использоваться Rich Client Arch в системах многоуровневого предприятия

Question

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

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

Как-то это просто не чувствует себя хорошо ко мне по следующим причинам:

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

и т.д., и т.д.

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

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

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

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

---

Смотрите также: Google Earth - Rich Client or Rich Internet Architecture?

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

http://blogs.msdn.com/blogfiles/brada/WindowsLiveWriter/Whatis.NETRIAServices_8178/image_6.png

При использовании технологии Microsoft .Net есть RIA услуга, доступная для реализации этого:

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