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

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

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

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

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

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

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

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


.net architecture architectural-patterns loose-coupling separation-of-concerns
person Maxim Gueivandov    schedule 20.02.2011    source источник
comment
Нашел аналогичный вопрос: stackoverflow.com/questions/2876946/   -  person Maxim Gueivandov    schedule 20.02.2011

Ответы (4)


arrow_upward
2
arrow_downward

Вариант 3.

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

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

Я бы сгруппировал интерфейсы в отдельные сборки, подумав о Commom Closure и Общие принципы повторного использования. Будучи самостоятельными, они также будут более стабильными. Подумайте о сценариях, в которых они будут использоваться — имеет ли смысл держать их вместе — если да, то они, вероятно, подходят в одной сборке.

person Adrian K    schedule 21.02.2011

arrow_upward
2
arrow_downward

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

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

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

person benPearce    schedule 20.02.2011

arrow_upward
2
arrow_downward

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

person Robert    schedule 14.03.2011

arrow_upward
-1
arrow_downward

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

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

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

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

person John Farrell    schedule 20.02.2011
comment
SoC вызывается как картина целого; учитывая ваше предположение, если бы я хотел перевести SoC в физическую концепцию, мне пришлось бы создавать отдельные сборки для представлений и контроллеров, что в большинстве случаев совершенно бессмысленно. Далее, в примере, приведенном в моем вопросе, возможный ответ на вопрос, зачем вам нужна абстракция, довольно легко представить: переход на реализацию, в которой используется другой поставщик данных, что, как вы должны признать, имеет гораздо больше шансов, чем переход на галактическое время или любой другой смещенный иронический пример, который вы могли бы привести. - person Maxim Gueivandov; 20.02.2011