Przyjrzałem się prostszym aplikacjom, takim jak Nerddinner i ContactManager, a także bardziej skomplikowanym, takim jak Kigg. Rozumiem te prostsze, a teraz chciałbym zrozumieć bardziej złożone.Przeniesienie mojego MVC na wyższy poziom: DI i Unit of Work
Zazwyczaj prostsze aplikacje mają klasy repozytoriów i interfejsy (tak luźno powiązane, jak się da) na szczycie LINQtoSQL lub Entity Framework. Repozytoria są wywoływane przez kontrolery w celu wykonania niezbędnych operacji związanych z danymi.
Jeden wspólny wzór widzę kiedy zbadać bardziej skomplikowanych aplikacji, takich jak Kigg lub Oxite jest wprowadzenie (Jestem tylko zarysowania powierzchni tutaj, ale muszę zacząć gdzieś):
- IOC di (w Kigg użytkownika sprawa Unity)
- WWW Zapytanie Lifetime
- jednostka pracy
Oto moje pytania:
Rozumiem, że aby naprawdę mieć luźno powiązaną aplikację, trzeba użyć czegoś takiego jak Unity. Ale wydaje się, że w momencie wprowadzenia Unity do miksu musisz również wprowadzić Lifetime Manager Web Request. Dlaczego? Dlaczego aplikacje przykładowe, takie jak Nerddinner, nie mają Web Lifetime Manager? Co dokładnie robi? Czy to jest rzecz specyficzna dla Jedności?
Drugi wzór, jaki zauważam, to wprowadzenie Jednostki Pracy. Znowu to samo pytanie: dlaczego Nerddinner lub ContactManager nie używają jednostki pracy? Zamiast tego te aplikacje używają klas repozytoriów na Linq2Sql lub Entity Framework do manipulowania danymi. Brak oznak jakiejkolwiek Jednostki Pracy. Czym dokładnie jest i dlaczego powinno się go używać?
Dzięki
Poniżej znajduje się przykład DI w Nerddiner na poziomie DinnersController:
public DinnersController()
: this(new DinnerRepository()) {
}
public DinnersController(IDinnerRepository repository) {
dinnerRepository = repository;
}
Więc mam prawo przypuszczać, że ze względu na pierwszy konstruktor kontroler "posiada" THE DinnerRepository i będzie zatem zależeć od czasu życia kontrolera, ponieważ jest tam zadeklarowany?
Dziękujemy! To pomogło. Zmieniłem moje pytanie na dole. Czy to masz na myśli mówiąc, że kontroler jest właścicielem odniesienia do kontekstu repozytorium/danych? – Thomas
Niezupełnie. W NerdDinner używają dodatkowego konstruktora akceptującego IDinnerRepository, aby ułatwić testy jednostkowe. Ale tak, wciąż jest to kontroler (konstruktor bez parametrów) lub testy, które tworzą i są właścicielem obiektu repozytorium. Oboje umierają i nie ma innych użytkowników repozytorium; więc życie jest proste. Tak przy okazji, taka technika jest zła; możesz przeczytać więcej na ten temat tutaj: http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/07/03/how-not-to-do-dependency-injection-in-nerddinner.aspx (również jako google dla "IoC biedaka"). – queen3
Argument Jimmy'ego Bogarda o tym, że jest to rażący przykład "IoC biedaka" jest tutaj wyjątkowo dobry. Komentarze są również dobre. Zdecydowanie warte przeczytania. –