Куда поместить интерфейсы в компонентно-ориентированную архитектуру?
На самом деле на этот вопрос отвечают в Приложении документация Egnine. Посмотрите пример на Пользовательские изображения Загрузки .
код HTML, внутри < form> :
код Python:
class Guestbook(webapp.RequestHandler):
def post(self):
greeting = Greeting()
if users.get_current_user():
greeting.author = users.get_current_user()
greeting.content = self.request.get("content")
avatar = self.request.get("img")
greeting.avatar = db.Blob(avatar)
greeting.put()
self.redirect('/')
7 ответов
В двух словах Если интерфейсы являются общими, то они должны быть сгруппированы в общую сборку, в противном случае они должны быть в сборке интерфейсов компонентов.
Немного подробнее Если один из стандартизованных (т. Е. Общих) интерфейсов изменится независимо от того, где вы его разместите, вам придется изменить все компоненты, которые его реализуют, независимо от того, находится ли этот интерфейс в общей сборке или в компонентной. Таким образом, у варианта 1 нет особых недостатков, даже если, как вы говорите, вам, возможно, придется изменить только один интерфейс. С другой стороны, вы столкнетесь с недостатком репликации общих интерфейсов в каждом компоненте, см. Стандартные проблемы избыточности.
Это не специальное предложение, а естественный выбор с того момента, как вы (разумно) выбрали стандартизовать интерфейсов. Вы предприняли попытку идентифицировать их, вы обнаружили, что они являются стандартными, и теперь вы их группируете.
Если компоненты, реализующие эти общие интерфейсы, имеют в дополнение некоторые другие специальные интерфейсы, они должны быть в сборке компонентов, поскольку они не должны подвергаться воздействию других компонентов, имеющих доступ к общей сборке.
Все очень хорошие отзывы. И я хотел бы продвинуть общий консенсус «в умеренности».
Небольшой анекдот,
Я лично видел, как целые решения взрываются с быстрым увеличением функционально-специфичных сборок. Я также видел монолитные подходы. Повторяю: вам нужно что-то среднее.
В моих личных проектах я часто использую внедрение зависимостей [DI] и инверсию управления [IoC], а также использую Castle Windsor Container, чтобы сделать много тяжелой работы. Я также заранее определяю, какие компоненты требуют «широкого» охвата, а какие не требуют воздействия. Например, служба [скажем, сам контейнер или брокер событий] будет считаться «широкой», поскольку, вероятно, будет много и много потребителей этой службы во всем приложении.
Соглашение об организации полезно только в том случае, если оно служит своему потребителю [вам! разработчик!]
IMO Интерфейс (ы) для компонента должен находиться вместе с компонентом - возможно, в сборке интерфейсов конкретного компонента.
Любые «общие» типы данных должны существовать отдельно от компонентов (возможно, в «общий» или «общий» компонент).
Вы не можете сгруппировать интерфейсы в функциональные / доменные области? Таким образом, вы получите решение где-то посередине. Если нет, я бы пошел с объединением всех общих интерфейсов в одну сборку.
Я использую как можно меньше сборок, стремясь к единственной сборке, одновременно изолируя нестабильные области домена. Когда несколько сборок явно подходят или необходимы, я стараюсь сгруппировать интерфейсы, которые будут изменяться одновременно, в одни и те же сборки.
Недавно было хорошее обсуждение стоимости поддержки нескольких сборок. Эта статья особенно хороша для описания недостатков нескольких сборок, наблюдения за тем, как они увеличивают затраты во время разработки, компиляции, развертывания и выполнения.
Это зависит от назначения каждого интерфейса:
Если целью интерфейса является определение стандартного протокола между набором альтернативных поставщиков и одним потребителем, интерфейс принадлежит потребителю.
Если целью интерфейса является определение стандартного протокола между одним поставщиком и набором альтернативных потребителей, то интерфейс принадлежит поставщику.
Если целью интерфейса является определение стандартного протокола между набор альтернативных поставщиков и набор альтернативных потребителей, интерфейс стоит сам по себе.
Наконец, если интерфейсы используются как общий подход для уменьшения сложности,они, как правило, принадлежат потребителям, и их следует определять как можно более узко, чтобы каждый интерфейс поддерживал потребности потребителя в конкретном контексте требований.
Обычно вы создаете некую форму "общей" библиотеки, на которую должны ссылаться все компоненты в архитектуре. Здесь определяются и группируются все общие интерфейсы, перечисления и т. Д.
Итак, первым шагом при создании библиотеки, которая расширяется или вписывается в структуру, является ссылка на Common.DLL. Затем вы реализуете в этом конкретном модуле тот набор интерфейсов, который вам нужен.
Экстремальные решения, которые вы описываете, действительно очень экстремальны. Первый будет очень негибким и в основном ограничит возможность расширения вашей структуры. Второй вариант был бы очень гибким, но утопил бы ваш проект в надоедливом супе одноинтерфейсных DLL.