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

Question

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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