2010-11-09 5 views
3

Possible en double:
How to implement Unit of work in MVC: Responsibilityasp.net couche de service et mvc unité de travail

Salut. Je développe une application web ASP.NET MVC en utilisant l'architecture suivante: UI -> Contrôleur -> Service Layer -> Repository. La question ici est où exposer le modèle d'unité de travail. Par exemple j'ai:

public class SomeController 
{ 
    public ActionResult AnAction() 
    { 
     using(var unitOfWork = UnitOfWorkManager.Create()) 
     { 
      try 
      { 
       this.ServiceA.Foo(); 
       this.ServiceB.Foo(); 

       unitOfWork.Commit(); 
      } 
      catch(Exception ex) 
      { 
       unitOfWork.Rollback(); 
      }   
     } 
    } 
} 

Est-ce que le contrôleur peut connaître l'unité de travail? Que se passe-t-il si nous avons plusieurs appels à différents services mais dans la même méthode d'action et que nous avons besoin d'un comportement transactionnel?

+2

Votre question a également été discutée dans SO: http://stackoverflow.com/questions/2238428/ comment-mettre en œuvre-unité-de-travail-en-mvc-responsabilité – tshao

Répondre

4

Nous avons construit une application avec la même architecture et notre vue était que la classe UOW est utilisée exclusivement dans les services. Raisons:

  1. Nous pensons que les actions ne devraient avoir une logique de vue si possible ne devrait pas connaître les règles métier associées à l'utilisation du référentiel plusieurs appels
  2. règles logiques d'affaires devraient (autant que possible) dans un service. Nos services utilisent un ou plusieurs référentiels utilisant la classe UOW et un objet contextuel de courte durée.

L'action

public ActionResult List() 
{ 
    var things = ThingService.GetAll();    
    return View(things); 
} 

Le Service

public IEnumerable<Thing> GetAll() 
{ 
    using (ObjectContext context = new Container(ConnectionString)) 
    { 
     var work = new UnitOfWork(context); 
     return work.Things.GetAll()); 
    } 
} 

Hope this helps

+1

Merci, mais comment avez-vous géré le cas lorsque, par exemple, une action de l'utilisateur nécessite des opérations sur soi services veral, comme dans mon cas? D'après votre réponse, je suppose que l'objet ServiceA contiendrait une référence à l'objet ServiceB et à la méthode d'appel ServiceB.Foo() de ServiceA.Foo(). Je pense que cela complique l'architecture. – Markus

+3

Markus dans la plupart des cas nos services sont conçus pour encapsuler une logique de transaction. Donc, dans ce cas, si le service a traité toute la logique métier et a ensuite besoin d'envoyer un courrier électronique (un autre service), il connaît ce service (injecté à l'aide de l'injection de dépendances). Si c'est quelque chose de plus compliqué alors le modèle de Commande sur les Services vous permet de construire une transaction de services par ex. Une réservation de vol est modifiée et cela affecte une réservation de voiture associée. Mais nous l'avons fait pour que nous puissions mélanger et assortir les services, vous pourriez ne pas avoir besoin de cette flexibilité ... – abarr

+0

où appelez-vous 'Commit'? en fonction de votre exemple, chaque service devrait appeler 'Commit' par lui-même, mais dans le cas de plusieurs services interagissent entre eux, vous pouvez vous retrouver avec plusieurs trajets vers DB, n'est-ce pas? –

Questions connexes