расположение дилеммы интерфейсов

Question

Учитывая проект кода, который должен придерживаться принципа SoC путем реализации слабо связанных слоев, наличия контейнера IoC и т. Д., Например, простое решение ASP.NET MVC, которое разделено на следующие сборки:

• Приложение сборка + пространство имен
• Модель сборка + пространство имен (содержит конкретный репозиторий для доступа к данным БД)

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

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

2) Если вы поместите ее в сборку Application , она будетневозможно использовать сборку Model в других проектах без ссылки на сборку Application (Argh!)

3) Или вы создадите отдельную общую сборку только для этого интерфейсаи в этом отношении для каждого общего интерфейса или набора интерфейсов?(Argh?)

Подводя итог, можно сказать, что X сборка должна быть легко заменяемой в приложении A (просто путем изменения ссылки) и многократно использоваться в приложениях B, C , D .

Answer 1

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

Answer 2

Вариант 3.

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

Вы бы создали отдельную общую сборку только для этого интерфейса и, в этом отношении, для каждого общего интерфейса или набора интерфейсов?(Argh?)

Я бы сгруппировал интерфейсы в отдельные сборки, подумав о принципах Clomom Clom и Common Reuse .Будучи самостоятельно, они также будут более стабильными .Подумайте о сценариях, в которых они будут использоваться - имеет ли смысл их объединять - если это так, то, вероятно, они в порядке в одной сборке.

Answer 3

Вы можете просто использовать сборку Contracts или Interfaces, как вы предложили.

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

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

Answer 4

Найден похожий вопрос: Слабое соединение компонентов

Answer 5

SoC - это логическая концепция, которую вы пытаетесь перевести на физическую.

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

Я тоже не понимаю проблемы. Что мешает вам иметь Concrete1 : IRepository и Concrete2 : IRepository в сборке моделей?

Кроме того, вы, вероятно, неправильно что-то связываете, если ядро ​​вашего приложения должно быть изменено изменением ваших классов Model. Это немного назад.