2013-03-19 11 views
35

Mam istniejący projekt, który używa AutoFac jako IoC.Jaka jest różnica między DependencyResolver.SetResolver i HttpConfiguration.DependencyResolver w WebAPI

W kodzie rejestracyjnym mam te linie:

var resolver = builder.Build(); 
DependencyResolver.SetResolver(new AutofacDependencyResolver(resolver)); 
config.DependencyResolver = new AutofacWebApiDependencyResolver(resolver); 

Więc moje pytanie brzmi, jaka jest różnica między DependencyResolver.SetResolver i HttpConfiguration.DependecyResolver? Dlaczego powinienem je przypisać?

Odpowiedz

38

zapobiec przemieszaniu MVC i Web API w tym samym projekcie. Microsoft wydaje się to sugerować, ponieważ szablon Visual Studio dla Web API automatycznie miesza projekt z MVC, ale jest to zły pomysł.

Z architektonicznego punktu widzenia MVC i Web API są zupełnie inne. MVC to technologia interfejsu użytkownika mająca na celu optymalizację komfortu użytkownika końcowego. Web API to technologia serwisów internetowych, która ma na celu optymalizację działania dewelopera (klienta).

MVC i Web API nie udostępniają żadnego konkretnego kodu prezentacji. Połączenie ich w tym samym projekcie powoduje, że projekt jest większy i bardziej skomplikowany.

Ale może nawet ważniejsze, oba typy aplikacji mają własne potrzeby konfiguracji DI. Mają własne Composition Root i mieszanie go w jedną konfigurację DI (pojedynczy pojemnik DI) może sprawić, że twoja konfiguracja będzie wyjątkowo trudna.

Wreszcie, połączenie Web API z MVC w tym samym projekcie prowadzi do bolesnych niejednoznacznych konfliktów nazw, ponieważ zespoły Web API zawierają wiele klas o tej samej nazwie co odpowiedniki MVC (ale z nieco innymi implementacjami).

+0

OK, ale załóżmy, że muszę zapisać kilka dodatkowych danych przed uruchomieniem WebApi, w tym przypadku chcę użyć mojej warstwy DAL z pliku global.asax i chcę, aby została ona wstrzyknięta. Naprawdę nie widzę problemów z miksowaniem/ponownym użyciem tej samej konfiguracji DI w tym przypadku? Projekt Web API jest całkowicie oddzielony. –

+3

Jest bardzo często dla wielu aplikacji końcowych ponowne użycie tej samej warstwy biznesowej lub innych udostępnionych złożeń. Jeśli znajdziesz duplikat kodu zarówno w projekcie MVC, jak i Web API, brakuje zestawu współdzielonego. W przypadku niektórych części konfiguracje DI wyglądają podobnie i zasada DRY nadal obowiązuje: zapobiegaj duplikacji poprzez wyodrębnienie tej części do wspólnego zestawu i pozwól każdej aplikacji końcowej zakończyć konfigurację w sposób odpowiadający jej potrzebom. – Steven

+1

@Steven - odpowiedzi takie nie są w ogóle pomocne i dlatego głosowałem na to z tego powodu. Wyjaśnienie Marka było wszystkim, co było naprawdę wymagane (wyjaśnienie różnicy między tymi dwoma rewolwetami), i ja też głosowałem na to z tego powodu. O ile nie zostało to wydane przez Jevgenija, MVC w ogóle o nim nie wspomniano, AutoFac był. –

17

DependencyResolver.SetResolver jest konstruktem MVC i jest wymagany do obsługi IOC przy użyciu MVC.

Specyfikacja internetowa jest określana jako GlobalConfiguration.Configuration.DependencyResolver.

Będziesz potrzebował obu, jeśli chcesz wspierać zarówno MVC, jak i WebApi w ramach tego samego projektu.

To może być również podkreślić, że normalnie nie trzeba jawnie ustawić DependencyResolver.SetResolver jako Ninject Mvc3 ma bootstrap dla tego ... zobacz here

35

Chyba pomieszane między MVC i Web API

DependencyResolver.SetResolver 

jest for MVC i należący do zespołu System.Web.Mvc. W przeciwnym razie:

Configuration.DependencyResolver 

dla Web APi, należy do zespołu System.Web.Http.

Więc w projekcie, wykorzystuje zarówno MVC i Web API, dlatego widać dwie linie do konfiguracji IoC dla każdego

+1

była to także zwięzła i odpowiednia odpowiedź na zadane pytanie, więc również ją głosowałem. –

Powiązane problemy