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

Question

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

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

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

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

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

Любые мнения приветствуются.

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

Answer 7

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

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