Wohin mit Datenmanipulation und Geschäftslogikcode in ASP.NET MVC-Anwendung?

Question

Nachdem ich Samples von der Cona-Anwendung von Rob Conery gesehen habe, sehe ich, dass er zwei Dinge mit IoC verwendet - ISession, wo er Datenschichtcode und Dienste hat, wo er zusätzliche Geschäftslogik hat, die wir beim Manipulieren von Daten im Datenspeicher ausführen müssen . Zum Beispiel können wir nicht nur einen Datensatz zur DB hinzufügen, sondern auch Eigenschaften eines anderen Datensatzes ändern, einige Zählungen erhöhen, etwas zurücknehmen usw. Wir müssen diesen zusätzlichen Code irgendwo einfügen und er fügt ihn in diese Dienste ein.

Zum Beispiel hat er einen CustomerService, der Kunden manipuliert. Dazu müssen wir die ISession-Instanz an CustomerService senden, damit der CustomerService sie für den Zugriff auf den Datenspeicher verwenden kann.

Jetzt wäre eine weitere Möglichkeit, diesen zusätzlichen Code in die Customer-Klasse selbst zu schreiben und die ISession (oder IRepository, welche Terminologie wir auch verwenden) an diese Klasse zu senden. Und keine Dienste haben. In der Regel sind Kunden-, Auftrags-, Produkt- und andere Klassen Modellklassen. Dies würde zu großen/schweren Modellklassen führen.

Meine Frage ist, welche Lösung ist besser? Bisher hatte ich das nicht nötig, weil ich den größten Teil des Codes in den Controllern hatte, aber jetzt, da meine Anwendung wächst, muss ich eine Entscheidung darüber treffen und die Controller aufräumen.

Zur Zeit habe ich: - Fett-Controller mit Business-Logik darin, - sehr atomaren Repositorys - sehr sauber Modelle und Viewmodels.

Soll ich bewegen zu: - slim-Controller, - Repositorys mit mehr Code, - Modelle mit Logik-Code-Geschäft (sollen speziell meine Modellklassen enthalten Methoden wie Add(),() entfernen, zum Beispiel Customer.Remove() ??)

oder - slim-Controller, - Atom-Repositories, - noch saubere Modelle, - Dienstleistungen (einzukapseln alles andere, die nicht in einem der vorherigen geht).

Answer 1

Ich würde empfehlen, dass Sie Repositories mit atomaren Operationen mit den Modellklassen und der Serviceebene haben, die von diesen Repositorys abhängen, um Geschäftsvorgänge zu definieren. Das Konzept von AOP könnte verwendet werden, um eine SQL-Transaktion zu Beginn jeder Geschäftsoperation automatisch zu starten und im Falle einer Ausnahme am Ende oder Rollback zu committen.

Schließlich werden Controller diese Serviceklassen verwenden und zwischen den Domänenmodellen und Ansichtsmodellen konvertieren.