2008-09-11 9 views
5

Podoba mi się pomysł oddzielenia interfejsów i implementacji. Ale jak oddzielne? Czy definicje interfejsu znajdują się w osobnym zestawie .Net? Czy masz jeden projekt, który definiuje wszystkie interfejsy dla rozwiązania? W przeciwnym razie są problemy z okrężnymi zależnościami interfejsów?Gdzie interfejsy "fizycznie żyć"?

Odpowiedz

7

Umieść obiekty domeny i interfejsy w osobnym zestawie "domeny".
Ten zestaw nigdy nie powinien odwoływać się do niczego poza podstawowymi zespołami .net.

W ten sposób uzyskasz czystą separację od modelu domeny/usługi i implementacji.

Edit:
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

+0

Pomyślałem, że warto zamieścić link do znakomitego artykułu Jeffery'ego Palermo na temat architektury cebuli http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ –

+0

Dzięki. Ten artykuł bardzo dobrze wyjaśnia tę koncepcję. –

3

Nie chciałbym umieścić interfejsy do oddzielnego zespołu właśnie przez wzgląd na niego. Jeśli jednak interfejsy biorą udział w dowolnej formie architektury IPC lub rozszerzalności, często ma to sens, aby nadać im własny zespół.

Jeśli masz projekty, które muszą się do siebie nawzajem odwoływać, to tak, będziesz potrzebować oddzielnego zestawu dla interfejsów, ale powinieneś również dokładnie przeanalizować architekturę, aby dowiedzieć się, czy istnieje inny sposób rozwiązania zależności cyklicznej.

1

Wolę zachować najpopularniejsze lub najprostsze implementacje interfejsu w podfolderze (i przestrzeni nazw) po nazwie interfejsu.

 
\project\ 
\project\IAppender.cs 
\project\Appender\ 
\project\Appender\FileAppender.cs 
\project\Appender\ConsoleAppender.cs 

Jeśli rozszerzę tę klasę poza projekt. W specjalnym projekcie powtórz folder/przestrzeń nazw podobnie.

 
\specialproject\ 
\specialproject\Appender\ 
\specialproject\Appender\MemoryAppender.cs 
0

W projekcie, nad którym pracuję teraz, interfejsy i powiązane klasy bazowe przechodzą na zespoły, które są logicznie rozdzielone między funkcje. Implementacje tych dostawców i klas mieszczą się w głównym zespole. Idea polega na tym, że ludzie używający naszego API mogą odwoływać się do większej lub jednej biblioteki DLL w jasny i logiczny sposób.

Mniejsze zastosowania nie wymagają tego rodzaju separacji. Ale bez względu na to, gdzie zachowam interfejsy, zachowam je w tej samej przestrzeni nazw co wszystkie klasy bazowe.