Модули на одном уровне в многоуровневой архитектуре

Question

Теоретически в многоуровневой архитектуре вы можете иметь несколько модулей на одном уровне. Могут ли эти модули перекрестно ссылаться друг на друга? Возможно технически, например. используя .NET?

Answer 1

Это, безусловно, можно сделать, просто будьте осторожны, чтобы не вводить никаких циклических зависимостей между модулями. В общем, модули на данном слое должны зависеть только от других модулей от того же уровня или от слоев ниже. Модули не должны знать о слоях над ними.

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

Поддержание открытого интерфейса до минимума, например. выставляя только основной набор открытых интерфейсов, объектов значений и исключений, всегда является хорошей идеей. Вы можете использовать функции управления доступом на языке (то есть private/package/public), чтобы ограничить видимость внутренних компонентов модуля от разлива на другие слои.

Answer 2

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

Но нам нужно немного взглянуть на слово «слой», поскольку слои имеют разные формы и размеры. Часто, когда мы используем слово «слой», мы считаем, что Data Access Layer или Presentation Layer, и мы обычно позволяем слоям смотреть вниз, но не upwars.

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

Только нет двух модулей, которые связывают друг с другом, прямо или косвенно. Если вы обнаружите, что A и B обе имеют функциональность друг от друга (что означает, что A и B находятся на одном уровне), вам, вероятно, придется реорганизовать код, возможно, представив новый модуль C, логически расположенный ниже A и B, который оба из них можно использовать.

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

Answer 3

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

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

Есть некоторые логические исключения из этого правила, например, в чем-то вроде модели домена - у клиента будет несколько заказов. В этом случае может быть полезно (например, с ORM и т. Д.) Иметь список заказов у ​​клиента и ссылку на клиента с каждого заказа. Что касается единиц функциональности, таких как сервисы и т. Д., То должны быть только односторонние зависимости.

Один из способов обойти эту проблему - использовать инверсию управления через Windsor, autofac, spring.net и т. Д. Вы можете определить интерфейс в сборке и другой объект, который использует конкретную реализацию этого интерфейса. Другая библиотека может содержать фактическую реализацию (это означает, что сборка должна ссылаться на первую сборку). В этом случае контейнер IoC захватывает реализацию.