Слабая связь компонентов

Question

Я создал библиотеку классов (сборку), которая обеспечивает обмен сообщениями, электронную почту и смс. Эта библиотека классов определяет интерфейс IMessenger, который оба класса EmailMessage и SmsMessage реализуют.

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

Теперь на моем прикладном уровне у меня есть класс, который требует использования компонента обмена сообщениями, и я, очевидно, хочу использовать созданную мной библиотеку сообщений. Кроме того, я буду использовать контейнер IoC (Spring.net), чтобы позволить мне внедрить мою реализацию, т.е. либо электронную почту, либо смс.

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

Это тесно связывает мой класс прикладного уровня с моей библиотекой классов сообщений?

Должен ли я определять интерфейс - IMessenger в отдельной библиотеке?

Или я должен заниматься чем-то другим?

Answer 1

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

Более того, не переусердствуйте в архитектуре. У него должна быть цель, и выгоды должны быть больше затрат.

Answer 2

Все зависит от ваших будущих планов на IMessenger.Лично я не считаю, что наличие интерфейса и нескольких примеров реализации в одной сборке - это плохо.Если кто-то захочет предоставить новую реализацию IMessenger, ему придется сделать это в другой сборке, и в процессе внедрения вашей сборки они получат EmailMessage, SmsMessage и т. Д. Для облегченной сборки я считаю, что это не имеет большого значения., поскольку это избавляет вас от необходимости ссылаться на сборки «интерфейс» и «реализация» каждый раз, когда вы хотите использовать одну из них.

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

Answer 3

Мои ответы на ваши вопросы:

• "Поэтому я хочу программировать на интерфейсе в моем классе прикладного уровня, нужно ли мне тогда ссылаться на мою библиотеку классов сообщений из моего класса прикладного уровня?" НЕТ

• "Это тесно связывает мой класс прикладного уровня с моей библиотекой классов сообщений?" ДА

• "Должен ли я определять интерфейс - IMessenger в отдельной библиотеке?" ДА

Если вы используете контейнер IoC, ПОЖАЛУЙСТА, вставьте зависимости и не связывайте ваше приложение с реализациями инфраструктуры.

Моя реализация заключалась бы в том, чтобы поместить интерфейс IMessenger на уровень приложения, чтобы объекты моего приложения могли общаться с интерфейсом, независимо от его реализации. Я бы имел общую электронную почту и отправку SMS в отдельной сборке, и они реализуют IMessenger. Впрыск, очевидно, выполняется контейнером IoC.

Прикладной уровень не должен знать инфраструктурный слой.

Это хорошая страница для просмотра проектов такого типа: Шестиугольная архитектура .