Простые советы по снижению сцепления

Question

У меня большое веб-приложение .NET. В системе есть проекты для разных целей (например, CMS, Forum, eCommerce), и я заметил (наивный) шаблон вызова в классе другого проекта. Например, модулю электронной коммерции нужна функциональность для создания файла «на лету» для продуктов, и я вызываю и ссылаюсь на метод в CMS, чтобы сделать это, потому что обработка файлов - это действительно работа для CMS.

Очевидно (и я знаю почему), это плохой дизайн и случай сильной связи.

Я знаю несколько способов справиться с высокой связью, например, реструктурировать проект (хотя я не думаю, что это надежное решение), но что еще я могу сделать, чтобы уменьшить высокую связь? Какие-нибудь простые советы? Также было бы полезно узнать, почему / как они уменьшают сцепление. Я использую .NET 3.5 и Sql Server 2005, поэтому такие вещи, как JMS (с которыми я постоянно сталкиваюсь при поиске советов по этой проблеме проектирования), неприменимы.

Спасибо

---

КСТАТИ

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

Я знаю о внедрении зависимости / IOC, но меня интересуют небольшие вещи, которые можно сделать, чтобы уменьшить связь.

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

Интересно, что в моем приложении я не хочу, чтобы оно было разобщенным. Поэтому у меня просто есть форум, система электронной коммерции и любой другой модуль, но все должно быть объединено в один сайт, поэтому каждый модуль (который представлен как отдельный проект в моем решении Visual Studio) должен знать о каждом другом модуле и работать с этим. Так, например, у меня может быть модуль, который обрабатывает профили пользователей (работа с членством ASP.NET, ролями и т. Д.), Но он будет работать с модулем форума, так как пользователь на форуме будет зарегистрированным пользователем на сайте (один войти в систему), и его или ее профиль будет поступать из модуля профиля пользователя. Это в отличие от отдельных профилей, как на других сайтах, с которыми я сталкивался).

Answer 1

Я бы подумал начать с рефакторинга «интерфейса извлечения» для тесно связанных частей. Например, если вы используете CMS в качестве резервного хранилища, создайте интерфейс, который может хранить вещи, затем создайте класс посредника или адаптера, который знает о CMS, но изолирует логику, которая знает о деталях механизма хранения, только с этим классом. 1001 *

Затем для тестирования вы можете легко заменить хранилище в памяти или хранилище локальной файловой системы, которое не зависит от работающей CMS.

Подумайте об использовании таких методов, как внедрение зависимостей (см. StructureMap, Spring.Net, NInject), чтобы упростить создание экземпляров, если простая фабрика не дает необходимой гибкости.

Answer 2

Вы должны выставлять веб-сервисы в тех проектах, которые понадобятся другим проектам. Это своего рода идея базового уровня, стоящая за SOA. Итак, я просто создал бы веб-сервисы и использовал бы их, что немного отделит вас от того, как вы это делаете сейчас. Надеюсь, это поможет.

Answer 3

Похоже, у вас есть проблема с наслоением. У ваших сборок должен быть один цикл зависимости - от наименее стабильного до наиболее стабильного. Это позволяет вам разумно делать версии. Обычно этот цикл будет выглядеть как UI (наименее стабильный) -> Domain Core (стабильный) -> Data Access (наиболее стабильный). По пути вы можете добавить утилиты или некоторые сборки инфраструктуры, но, опять же, их следует считать более стабильными, чем зависящие от них сборки.

Я полагаю, что ваши сборки App.ECommerce и App.Cms - больше братьев и сестер, чем слоев - так что вы бы не хотели, чтобы они зависели друг от друга, но это не значит, что вы не можете повторно использовать функциональность. Для вашего конкретного сценария вам необходимо передать необходимые функциональные возможности до сборки ядра или утилит, от которой могут зависеть как ECommerce, так и Cms. Если это конкретная реализация, которую предоставляет ECommerce, то вы можете перенести интерфейс или абстрактный базовый класс в Core - и иметь более высокий уровень (возможно, контейнер IoC) для подключения конкретного класса Cms.FileCreator к зависимости ECommerce.IFileCreator. *

Answer 4

1. Получите правильные абстракции на месте, как описано другими (интерфейсы и т. Д.). Программа против абстракций, а не конкреций.
2. Создайте свои классы с учетом внедрения зависимостей, как вы описали.
3. Используйте Инверсионный Контейнер Контроля в качестве раствора между кирпичами.

Unity из команды Patterns & Practices дополняет библиотеку Enterprise.

Скотт Хансельман имеет хороший Список инверсии управляющих контейнеров .NET .

Answer 5

Ну, я ничего не знаю о .NET, но как насчет рефакторинга общего кода в отдельный, лежащий в основе проект / слой? Множество вещей в веб-приложении можно сделать в общем, чтобы удовлетворить и CMS, и форум, и электронную коммерцию, и запись в файл - прекрасный пример.

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