Почему веб-архитектура должна быть слабо связана? - PullRequest
Новая
       33

Почему веб-архитектура должна быть слабо связана?

28 голосов
/ 19 мая 2010

Когда я смотрю на проекты ASP.NET MVC, я всегда вижу слабосвязанную архитектуру.

Для чего мне нужна слабая связь в веб-архитектуре (если я не выполняю модульные тесты)?

Каковы преимущества и недостатки этого?

Какова основная причина для разделения слоев / классов?

Что, если я не хочу менять свой DAL, например? Я имею в виду, когда я должен изменить весь мой DAL ?! Таким образом, я мог связать свой DAL с пользовательским интерфейсом. Что в этом плохого?

Ответы [ 13 ]

2 голосов
/ 19 мая 2010

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

1 голос
/ 20 мая 2010

Разделение труда, которое является человеческим эквивалентом разделения интересов. Ваш HTML-гуру должен работать независимо от вашей богини SQL.

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

0 голосов
/ 05 июля 2011

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

  • Архитектуры на основе очередей, в которых Интернет помещает сообщения в очередь и прослушивает результаты
  • Избегание блокирующих операций, в первую очередь с помощью асинхронного шаблона или асинхронной монады, которая связывает продолжения с обратными вызовами операций, позволяя потокам работать во время ожидания ввода-вывода. Пример: http://blogs.msdn.com/b/dsyme/archive/2007/10/11/introducing-f-asynchronous-workflows.aspx или http://en.wikibooks.org/wiki/Haskell/Continuation_passing_style
  • Архитектура на основе push (AMQP basic_consume, например)
  • Шаблоны вилочных соединений
  • ...

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

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

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

Для различных типов связывания типа компиляции (и других метрик), просмотрите http://www.ndepend.com/Metrics.aspx и прочитайте некоторые об этом сами.

Страница:
...