8

widziałem kod jak poniżej tutorial EF code first, MVC i StructureMap stworzyć Context Per Request wzoru:jest wymagana HttpContextScoped StructureMaped?

protected void Application_Start() 
    { 
     ... 

     initStructureMap(); 

    } 

    private static void initStructureMap() 
    { 

     ObjectFactory.Initialize(x => 
     { 
      x.For<IUnitOfWork>().HttpContextScoped().Use(() => new Context()); 
      x.For<IFirstEntity>().Use<FirstEntity>(); 
      x.For<ISecondEntity>().Use<SecondEntity>(); 
      x.For<IThirdEntity>().Use<ThirdEntity>(); 
     }); 

     ControllerBuilder.Current.SetControllerFactory(new StructureMapControllerFactory()); 
    } 

    protected void Application_EndRequest(object sender, EventArgs e) 
    { 
     ObjectFactory.ReleaseAndDisposeAllHttpScopedObjects(); 
    } 


public class StructureMapControllerFactory : DefaultControllerFactory 
{ 
    protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType) 
    { 
     return ObjectFactory.GetInstance(controllerType) as Controller; 
    } 
} 

FirstEntity, SecondEntity i ... wszyscy potrzebujemy IunitOfWork w ich konstruktora.

jak widać to po prostu wykorzystuje HttpContextScoped() dla innych i nie Context w przypadku EndRequest wywołuje ReleaseAndDisposeAllHttpScopedObjects().

1- czy to jest prawidłowe podejście?

2- należy użyć HttpContextScoped() dla wszystkich innych Service layer Interfaces lub nie tylko dla IUnitOfWork? np

x.For<IFirstEntity>().Use<FirstEntity>(); 

lub

x.For<IFirstEntity>().HttpContextScoped().Use(() => new FirstEntity()); 

3- ReleaseAndDisposeAllHttpScopedObjects() dysponuje wszystkie przykłady lub tylko dysponuje Context?

Odpowiedz

8

Konwencją dla aplikacji internetowych jest zachowanie tego samego kontekstu ORM/UnitOfWork podczas całego żądania http. Ma to na celu pracę z tymi samymi podmiotami podczas żądania, utrzymanie spójności danych i minimalizację wykonywanych wywołań bazy danych. Cykl życia HttpContextScoped zapewnia, że ​​ta sama instancja UoW jest używana podczas żądania dla wszystkich instancji, które mają na nim zależność.

Więc 1) Tak, to jest prawidłowe

Odnośnie reszty „interfejsów warstwy usług”, to zależy od tego, czy to musi być tego samego wystąpienia podczas całego wniosku. Zadaj sobie pytanie: "czy stan tego obiektu będzie potrzebny podczas całego żądania"? W przypadku większości "usług" tak nie jest. Zauważ również, że zrobienie czegoś "HttpContextScoped" spowoduje również, że wszystkie jego zależności pozostaną w tym zakresie.

To prowadzi mnie do powiedzenia 2), w większości przypadków, nie

ReleaseAndDisposeAllHttpScopedObjects zbywa wszystkie obiekty w kontenerze zarejestrowanej HttpContextScoped. Domyślnie obiekty są określane jako przejściowe (nowa instancja na wywołanie) w Structuremap.

Tak 3) Tylko instancja IUnitOfWork zostanie usunięta.

+0

Zaktualizowałem pytanie 2 –

+0

Zaktualizowana odpowiedź. O ile nie trzeba utrzymywać tego samego stanu lub instancja jest droga do stworzenia i może współużytkować stan podczas żądania, należy przejść z obiektami przejściowymi. – PHeiberg

+0

dziękuję, mój problem jest wtedy, gdy te wystąpienia zostaną usunięte? czy oni też dysponują w EndRequest, czy nie? –

Powiązane problemy