Ansicht und Domain-Modell, wo die Berechnung durchgeführt wird

Question

Ich habe gerade angefangen, View & Domain-Modell-Design in meiner MVC-Web-App, aber habe die Frage, wo Berechnungen und andere View-bezogene Aktionen durchführen. Ich werde versuchen, ein Beispiel zu geben.

My Domain Model (Linq2Sql)

public class Product 
{ 
    public int Id; 
    public string Name; 
} 

The View Modell mit neuer UserCount Eigenschaft, die Ich mag würde berechnen.

public class ProductViewModel 
{ 
    public int Id; 
    public string Name; 
    public int UserCount; 
} 

Mein Controller-Aktion sieht aus wie

public ActionResult _SelectionClientSide_Products() 
{ 
    IQueryable<Product> products = _repository.GetProducts(true); 
    var model = Mapper.Map<IEnumerable<Product>, IEnumerable<ProductViewModel>>(products);         
    return View(model); 
} 

ich nach Daten abfragen Repository-Methode und bekommen IQueryable<Product> und wo es zu ProductViewModel Liste. Aber ich muss auch einen anderen Abfragevorgang durchführen, um Benutzer für jedes abgefragte Produkt zu zählen und alle Werte ProductViewModel zuzuordnen. Welchen Entwurf sollte ich befolgen, um dies zu erreichen?

Die Beziehung zwischen Tabellen

Products -> Orders - > Users 

EDIT

ich mich entschlossen habe AutoMapper zu entfernen, weil es mehr Probleme als Vorteile gibt und meine eigene Builder, die alles enthalten, was ich brauche. Ich mache Feld zuweisen und auch Berechnung hinzufügen.

public ActionResult _SelectionClientSide_Products() 
    {   
     Data = new ProductViewModelBuilder(_repository).Build(); 
     return View(Data); 
    } 

namespace PC.Models 
{ 
      public class ProductViewModel 
      { 
       public int Id { get; set; } 
       public string Name { get; set; } 
       public int UsersCount { get; set; } 
      } 

      public class ProductViewModelBuilder 
      { 
       private readonly IDataAccess _repository; 

       public ProductViewModelBuilder(IDataAccess repository) 
       { 
        _repository = repository; 
       } 

       public IQueryable<ProductViewModel> Build() 
       { 
        return _repository.GetProducts().Select(p=> new ProductViewModel 
                     { 
                      Id = p.Id, 
                      Name = p.Name, 
                      UsersCount = _repository.CountUsers(p.Id) 
                     });   
       } 

      } 
     } 

Answer 1

Meiner Meinung nach, von der Zeit der Controller Modell-Setup ist es begonnen hat, soll es auf das Modell nicht mehr „Logik“ oder im Gespräch sein. Einen Builder zu haben, der das Modell erneut abfragt, ist eine schlechte Übung. Nicht wirklich "brechen" das MVC-Muster, aber immer noch schlechte Praxis. Ihr ViewModel ist von Ihrer DAL abhängig. Schlechter böser Junge. :)

Wenn Sie eine andere Abfrage ausführen müssen, sollte das in der ursprünglichen Abfrage eingekapselt werden. Anstatt _repository.GetProducts aufzurufen, rufen Sie eine andere Methode auf, die nicht nur die Produkte erhält, sondern auch die Anzahl. Erstellen Sie bei Bedarf ein DTO.

Dann sollten Sie Ihre Controller wie folgt aussehen:

public ActionResult _SelectionClientSide_Products() 
{ 
    var someDto = _repository.GetProductsAndUserCount(true); 
    var model = Mapper.Map<IEnumerable<SomeDto>, IEnumerable<ProductViewModel>>(someDto);         
    return View(model); 
} 

ich persönlich für generische Repositories über spezialisiertere gehen, wie ich mit 50 Unterschriften keine IProductRepository Schnittstelle wollen. Ich entscheide mich für LINQ IEnumerable<T> Erweiterungen (aka "Pipes und Filter"), die komplexe Abfragen ermöglicht und in meiner Domäne bleiben.

So ist meine Version des obigen wäre:

public ActionResult _SelectionClientSide_Products() 
{ 
    var someDto = _productRepository.Find().WithSomeCondition(true).ToSomeDto(); 
    var model = Mapper.Map<IEnumerable<SomeDto>, IEnumerable<ProductViewModel>>(someDto);         
    return View(model); 
} 

Auf einer seitlichen Anmerkung, warum sagen Sie AutoMapper verursacht Sie Probleme mehr Vorteile, die? AutoMapper hat mir Tonnen von repetitivem Code gespart. Wenn Sie wissen, wie man es richtig benutzt, ist es Ihr bester Freund. Übergibt das wichtigste NuGet-Paket in meiner aktuellen Anwendung.