Dependency Container - gdzie konfigurujecie serwisy z całej solucji?

0

Przykładowo aplikacja ASP MVC, w solucji znajdują się różne projekty ClassLibrary jak Business, Application itp. Jak wygląda w waszych projektach rejestracja takich serwisow z całej solucji? W main projekcie (MVC) rejestrujecie wszystkie serwisy, czy każdy projekt ma przykładowo swój Module(Autofac) lub Installer(Windsor), a w main projekcie (MVC) rejestrujecie te moduły? Jakie jest zalecane podejście i jakie niesie ze sobą plusy?

0

Mamy projekt DI, który ma referencje do wszystkiego oraz moduły spinające wszystko w zależności od targetu (asp, serwis, konsolówka)

0

W przypadku appki webowej MVC będzie to właśnie projekt MVC. Zazwyczaj mam klasę statyczną Bootstrapper lub coś w tym stylu w której wszystko podpinam, lub wywołuję extension methods jeśli konfiguracja jest spora i dzielę ją na mniejsze moduły żeby było czytelniej.

0

Pytanko

Czy jeżeli Context ma lifetime transientowy (MS DI), to jest różnica pomiędzy

public MyController(Context context, MyService service)
{

}

public MyController(Context context)
{
	_myService = new MyService(context);
}

Gdzie:

public class MyService
{
	public MyService(Context context)
	{
		
	}
}

I czy może to wpłynąć na śledzenie zmian obiektów (EF Core) w tym serwisie?

1

Każdy projekt ma swoje moduły, projekt startowy je znajduje i rejestruje.
Plusem jest to, że nie mam żadnego god-projektu, który ma referencje do wszystkich innych. Nie jest to może jakiś ogromny argument, ale jest mój i bardzo się z nim zgadzam.

0

@WeiXiao:
Nie wiem jak działa "DI od MS" ale context powinien zachowywać się jak "singleton".

@CSharpBeginner
To zależy, jaka jest złożoność ja lubię robić "moduły dla kontenera" na warstwę, ale jak mówiłem to zależy od złożoności projektu. Spinasz to w swoim "Composition Root" czyli takim jakby "Main'ie"

0

@Gworys:

Singleton? przecież to będzie co chwile mieć problem z tym, że już jakaś akcja jest wykonywana na tym contexcie, czy nie? Nie łatwiej rozdzielić context per request lub "potrzebę" niż dopisywać thread-safeness do singletona?

0

Singleton z kontenera to nie jest to samo co klasa statyczna i przy aplikacji "webowej" powinien się zachowywać podobnie do "per request".

0
Gworys napisał(a):

Singleton z kontenera to nie jest to samo co klasa statyczna i przy aplikacji "webowej" powinien się zachowywać podobnie do "per request".

No coś nie do końca jestem przekonany.Jeśli każdy request dostanie tą samą instancje to taki service chyba musi być thread safe. ?
Per request to masz Scope.

0
szydlak napisał(a):

No coś nie do końca jestem przekonany.Jeśli każdy request dostanie tą samą instancje to taki service chyba musi być thread safe. ?
Per request to masz Scope.

Dlaczego uważasz, że ten serwis i singleton z kontenera nie jest "thread safe".?

"Per request" powinien działać tak jak singleton tylko że "per request" czyli z innym "life time".

0

Singleton lifetime services are created the first time they are requested (or when ConfigureServices is run if you specify an instance there) and then every subsequent request will use the same instance.

That means all requests for the service pull the same object, which means no per-thread objects, and thus no thread safety.

A no masz rację.

1 użytkowników online, w tym zalogowanych: 0, gości: 1