Где разместить интерфейсы в компонентной архитектуре?

Question

В архитектуре с компонентами, где большое количество развязанных компонентов взаимодействует через набор стандартизованных интерфейсов - существуют ли какие-либо рекомендации по использованию интерфейсов «где-к-хранилищу/как-к-группе»?

Экстремальные решения будут:

• Все в той же сборке (и вперед)
• один узел для каждого интерфейса

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

В частности, Я ищу аргументы KILLER, чтобы не принять две крайности выше и, очевидно, альтернативные варианты.

Любые мнения оценены.

Answer 1

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

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

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

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

Answer 2

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

Итак, первый шаг создания библиотеки, которая распространяется или вписывается в структуру, - это ссылка на Common.DLL. Затем вы реализуете любой набор интерфейсов, который вам нужен в этом конкретном модуле.

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

Answer 3

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

Недавно было проведено хорошее обсуждение стоимости обслуживания нескольких сборок. This article особенно хорошо описывает недостатки нескольких сборок, наблюдая, как они добавляют затраты во время разработки, время компиляции, время развертывания и время выполнения.

Answer 4

Не можете ли вы объединить интерфейсы в функциональные/доменные области? Таким образом, вы получите решение где-то посередине. Если нет, я бы поставил все общие интерфейсы в одну сборку.

Answer 5

IMO Интерфейс (ы) для компонента должен находиться вместе с компонентом - возможно, в сборке компонентов с конкретными компонентами.

Любые «общие» типы данных должны жить отдельно от компонентов (возможно, в «общем» или «общем» компоненте).

Answer 6

Все очень хорошие ответы. И я хотел бы содействовать общей консенсусе «в меру».

Быстрый анекдот Однако

Я лично видел целые решения, которые взрываются с распространением определенной функции узлов. Я также видел монолитные подходы. Повторяю: вы хотите что-то между ними.

В моих личных проектах я использую много инъекций зависимостей [DI] и инверсии управления [IoC], а также использовать контейнер Castle Windsor для многого тяжелого подъема. Я также заранее определяю, какие компоненты требуют «широкого» масштаба, и какие из них не требуют воздействия. Например, служба [скажем, сам контейнер или брокер событий] будет считаться «широким», так как, вероятно, многие пользователи этой услуги могут пользоваться во всем приложении. Компонент, который изолирован [скажем, форматирующий формат даты], будет не быть широким, так как никто не заинтересован в том, чтобы потреблять его напрямую, за исключением того, для которого он предназначен.

Широкие интерфейсы, я бы разместил отдельную сборку SomeProductName.Interfaces.

Бизнес-интерфейсы могут быть размещены в их собственной функционально-ориентированной сборке SomeProductName.SomeStuffForAlice и SomeProductName.SomeStuffForBob, как правило, той же библиотекой, что и ее реализация.

Ассембли являются лишь физическим представлением организации-источника - они фактически ничего не означают сами по себе [то есть монолитный затор, хотя и отталкивает, функционально эквивалентен хорошо организованному решению и тревожному проекту за один кошмар интерфейса) ,

Организационное соглашение полезно только в том случае, если оно служит его потребителю [вы! разработчик]

Answer 7

Это зависит от цели каждого интерфейса:

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

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

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

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