In MVC wo Berechnungen durchzuführen, wenn Daten von UI kommen?

Question

Ich habe gelesen, wo Geschäftslogik in ASP.NET MVC Project zu setzen, und ich kann immer noch nicht klar in einigen Dingen. Insbesondere die Berechnungen oder Geschäftslogik ausführen, wenn die Daten von der Benutzeroberfläche kommen.

Ich habe ASP.NET MVC-Anwendung mit EF. Die Anwendung ist eine typische 3-Tier-Anwendung.

UI - has View Models 
    Domain (aka Service Layer) - has DTO classes 
    DAL - has EF entities 

Jede Schicht hat ihre eigenen Klassen C# verwendet, um Daten zwischen den Schichten zu übertragen.
UI Bezug auf DomainDomain und hat Bezug auf DAL
Die Geschäftslogik der Anwendung ist in Domain (Service-Layer)

Typischerweise jede Art von Business-Logik/Berechnungen werden in Dienstschicht durchgeführt. Und das ist richtig, wenn die Daten von der Datenbank kommen.

Aber was ist, wenn die Daten von UI kommen?

Nehmen wir an, die Ansicht ist bereits mit mehreren Feldern gerendert. Im UI-Layer gibt es ein entsprechendes View-Modell. Ein Benutzer aktualisiert einige Felder und klickt auf eine Schaltfläche, die einen AJAX-POST zur Controller-Aktion macht. Der Server verfügt jetzt über ein gefülltes Ansichtsmodell, das von der Benutzeroberfläche stammt. Jetzt möchte ich einige Berechnungen durchführen und json Daten zurückgeben.

[HttpGet] 
public ActionResult Index(int id) 
{ 
    MyViewModel model = _service.GetModel(id); 
    return View(model); 
} 

[HttpPost] 
public ActionResult Calculate(MyViewModel model) 
{ 
    // preform calculations but where?? 
    var differentmodel = PerformCalculations(model); 
    return Json(someDifferentmodel); 
} 

Da Domain Schicht keinen Zugriff haben Modelle auf anzeigen i nicht MyViewModel-Domain passieren kann und dort die Berechnung tun.
Eine Möglichkeit sehe ich hier wie unten

public ActionResult Calculate(MyViewModel model) 
{ 
    1> Convert MyViewModel to DTO 
    2> pass DTO to service layer for calculations 
    3> get calculated DTO from service layer. 
    4> Convert DTO to differentViewModel 

     return Json(differentViewModel); 
} 

Es gibt viele zurück & hervor Abbildung, die unnötig erscheint.

Gibt es einen besseren Ansatz?
In Bezug auf die Design-Praxis, ist es in Ordnung, eine neue Schicht zwischen UI und Domain einzuführen, die sich sowohl auf UI als auch auf Domain bezieht. Diese neue Schicht ist verantwortlich für die Geschäftslogik/Berechnungen. Tatsächlich kann ich diese Ebene für Berechnungen verwenden, unabhängig davon, ob die Daten von der Benutzeroberfläche oder der Domäne stammen. Was wäre diese Schicht? (Ich weiß, technisch kann ich das tun, aber ich frage, ist es empfohlene Design-Praxis)

Answer 1

Sie machen dies unnötig komplex. Die erste Frage ist: "Ist diese Berechnungslogik nur für die Ansicht relevant oder ist sie an anderen Stellen wie der DAL anwendbar? Wenn sie nur für die Ansicht relevant ist, lege sie auf dein Ansichtsmodell. Wenn sie breiter anwendbar ist dann lege es in eine Klassenbibliothek oder etwas, das Referenz für alle Projekte ist, die es brauchen.Im letzteren Fall würden Sie wahrscheinlich nur eine Hilfsklasse erstellen, die die Berechnungen durchführt, und Sie würden nur die relevanten Daten eingeben, die Sie erstellen müssen Diese Berechnungen

Dann können Sie in Ihrer UI-Schicht entweder das Ansichtsmodell oder eine andere Hilfsklasse verwenden, um das Ansichtsmodell spezifisch zu behandeln.Zum Beispiel:

Klassenbibliothek

public static class CalculationHelper 
{ 
    public static int Add(int a, int b) 
    { 
     return a + b; 
    } 
} 

UI

public class MyViewModel 
{ 
    ... 

    public FooBarSum 
    { 
     get { return CalculationsHelper.Add(Foo, Bar); } 
    } 
} 

ODER

public static class UICalculationsHelper 
{ 
    public static int Add(MyViewModel model) 
    { 
     return CalculationsHelper.Add(model.Foo, model.Bar); 
    } 
}