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

Като се има предвид кодов проект, който трябва да се придържа към принципа на SoC чрез внедряване на слабо свързани слоеве, наличие на IoC контейнер и т.н., например просто решение ASP.NET MVC, което е разделено на следните сборки:

  • Сглобяване на приложение+пространство от имена
  • Модел сборка+пространство от имена (съдържа конкретно хранилище за достъп до DB данни)

и когато конкретно хранилище в сборката на модела трябва да реализира общ интерфейс IMyBusinessRepository, в коя сборка бихте поставили този интерфейс?

1) Ако поставите този интерфейс в сборката Модел, шансовете са, че ще бъде невъзможно да замените тази сборка с друга (поне ако има различно пространство от имена), без да модифицирате кода на < em>Приложение монтаж. Също така, алтернативна IMyBusinessRepository реализация, намираща се в различен асембли, би трябвало да препраща към оригиналната (Argh!)

2) Ако го поставите в сборката Приложение, ще бъде невъзможно да използвате сборката Модел в други проекти, без да препращате към сборката Приложение ( Ааа!)

3) Или бихте създали отделна обща сглобка само за този интерфейс и по този въпрос за всеки общ интерфейс или набор от интерфейси? (Ара?)

За да обобщим, сглобяването на X трябва да може лесно да се сменя в приложение A (само чрез промяна на препратка) и да се използва повторно в приложения B, C, D.


.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