Nie rozumiejąc gdzie utworzyć IoC kontenerów w architekturze systemu

Question

Say mam następujące zespoły: 4 .net

1. WinForm UI
2. Biznes Logic
3. SQL Server Data Access (wdrożenie IRepository)
4. Wspólne interfejsy (definicja IRepository itp.)

Moja logika biznesowa (2) wykonuje połączenia z warstwą dostępu do danych (3) poprzez IRepository (zdefiniowane w 4) za pomocą iniekcji zależnej od konstruktora. Jednak kiedy kończę obiekt biznesowy, muszę przekazać go do rzeczywistego repozytorium. Robię to, mając pojedynczą klasę w mojej warstwie logiki biznesowej, zwracając aktualnie wykorzystywany konkretny obiekt implementujący IRepository. Doszedłem do wniosku, że jest to złe, ponieważ moja warstwa logiki biznesowej musi teraz odwoływać się do 3, a także 4.

Myślę, że potrzebuję kontenera IoC, ale pytanie jest, gdzie utworzyć/umieścić go jako wydaje się, że gdziekolwiek to tworzę (1-UI)? będzie również musiał posiadać odniesienie do 3 (SQL Server Data Access). Czy nie tylko poruszam problem, a nie osiągam faktyczne oddzielenie?

Czy utworzyć kontener IoC w interfejsie użytkownika. Lub wystaw go przez inny nowy zespół.

(używam C#, .NET 3.5 i AutoFac)

Dzięki.

Answer 1

IoC kontener generalnie powinny być tworzone w gospodarza projektu (aplikacja punkt odbioru). Dla aplikacji Windows.Forms, która jest projektem exe.

Generalnie w prostych rozwiązaniach (poniżej 10 projektów) tylko projekt główny powinien mieć odniesienie do biblioteki IoC.

PS: Structuring .NET Applications with Autofac IoC

Answer 2

Rozróżnienie modułów i "zakresy" zdefiniowane przez moduły istnieją głównie podczas kompilacji. W czasie wykonywania jest to jeden wielki bałagan;) Jest on używany przez większość kontenerów IOC i nie obchodzi ich, gdzie się znajdują. Kontener IoC dla aplikacji internetowej będzie zazwyczaj tworzony na najbardziej zewnętrznym poziomie (bardzo blisko samego kontenera sieciowego).

Answer 3

To prawda, że ​​można go utworzyć w dowolnym miejscu, ale wprowadziłbym dodatkową warstwę, nazwijmy ją 3.5.

Twoje obecne 3 będzie miejscem zamieszkania IoC w celu uzyskania dostępu do danych - stanie się to opakowaniem dla rzeczywistego DAL. Na podstawie twojej konfiguracji 3 utworzyłoby fałszywe repozytorium lub konkretne.

Tak więc 2 nadal odwołuje się do 3, ale jest to tylko interfejs do rzeczywistego DAL, który jest skonfigurowany za pomocą struktury IoC.

Alternatywnie, można toczyć własną 'el-cheapo' IoC - zmień swój Big Ugly Singleton do statycznego Gateway - Abstracting IoC Container Behind a Singleton - Doing it wrong?

Answer 4

Przy rejestracji komponentów istnieje kilka możliwości:

1. rejestracji w Kod:

   • bezpośrednio
     problem: trzeba odwołać wszystko (jesteś tutaj)
   • pośrednio
     Problem: dowiedzieć się, co musi zostać zarejestrowany
     Rozwiązanie:
     1. użycie atrybutów
     2. wykorzystanie interfejsu marker jak IService
     3. stosowanie konwencji (zob StructureMap)

2. Rejestracja z plikiem konfiguracyjnym:

   • niech pojemnik zrobić wszystko
   • odczytać pliku samemu

Answer 5

Najwyższy poziom jest droga (UI, jak Rinat powiedział).

Jeśli chodzi o referencje, najprostszym sposobem jest po prostu przejrzenie wszystkich złożeń w bieżącym folderze i skorzystanie z niektórych konwencji w celu uzyskania usług. Atrybuty działają poprawnie, więc rejestrowanie zajęć w każdym zestawie działa dobrze, cokolwiek ci pasuje. Kod do wyodrębniania wszystkiego powinien prawdopodobnie znajdować się w osobnym zestawie, chyba że twój framework IoC już to robi.