Logische Code Trennung mit asp.net mvc4 - Best Practice vorhanden?

Hallo,

ich habe längere Zeit mit WPF gearbeitet (das ist jetzt auch wieder etwas her) und habe mich vor kurzem mit JavaEE JSF beschäftigt und schau mir nun ASP.NET MVC 4 genauer an.

In WPF Anwendungen konnte ich die Business Logik gut mit dem MVVM Pattern Trennen. Also alles was irgendwie zwischen View und dem Business war landete im ViewModel. So z.B. Validations Rules.

Dieses Prinzip konnte ich gut im JAVA EE JSF Projekt anwenden. Ich schreibe deshalb, dazu kurz was wie man das in JSF macht, damit man die unterschiede zwischen den beiden Technologien erkennt.

Man legt seine View, also die aufrufbare Page an und hat dann für jede dieser Pages ein ViewModel erstellt die für die View angepasst sind (natürlich könnte man die ViewModeles auch auf anderen Views wieder verwenden und es gibt auch Fälle wo es durchaus Sinn macht das zu tun).

Die Pages können dann durch den Viewnamen aufgerufen werden. Es gibt diverse RewriteRule Libaries in denen man die URLs zu den Seiten konfigurieren kann ohne in Berührung mit einem Controller zu kommen.

Ein Viewcode die auf eine Propertie oder Funktion zugreifen könnte in JSF z.B. so aussehen:

[...]
<customcontrol:dataTable id="dataTable" var="Element" value="#{ViewModel.ListeMitElementen}" scrollRows="60" scrollable="true" liveScroll="true" scrollHeight="400"
                                     filteredValue="#{ViewModel.FilterPropertie}">  
                            <p:column headerText="name">  
                                <h:outputText value="#{Element.name}" />  
                            </p:column>  
                            <p:column headerText="bearbeiten">  
                            <p:column headerText="lsöchen">  
                                <StandardLib:commandButton action="#{ViewModel.removeElement(Element)}" value="löschen" />
                            </p:column>  
                        </p:dataTable>
[...]

Daraus ergibt sich die Situation, dass man einen Controller im herkömmlichen Sinn wie in ASP.NET nicht mehr benötigt. Einzig allein um z.B. Encoding, Authentifizierung, ReWriteRules und der gleichen zu realisieren. Im Controller taucht kein Code auf der irgenwie etwas mit der View zu tun haben könnte. Genau das stört mich an ASP.NET MVC. Meiner Meinung sind die Views und die Controller viel zu eng mit einander verzahnt und zu viel von einander abhängig.

Auch gibt es, wenn ich mich nicht täusche, kein Best Practice um CustomControls zu realsieren. Man muss auf die ASP.NET Webforms zurückgreifen. Eine andere Methode wäre diese folgend zu realisieren http://www.codeproject.com/Articles/32356/Custom-controls-in-ASP-NET-MVC (macht man das noch so? Der Artikel ist etwas älter)

Validations sind in den Controller und auch die Methoden die die Formulare auswerten. Klar kann man im Controller die Formular Methode dem ViewModel übergeben, aber warum so umständlich?

Meine Frage ist, gibt es Frameworks die diese Problematik angehen und seht ihr das auch in etwa so wie ich?

Würde mich über interessante Beiträge dazu freuen.
SG

PS:Muss zwar mit asp.net mvc4 arbeiten aber würdet ihr dann trotzdem das "Pro ASP.NET MVC 5" buch empfehlen?

Bei MVC gibts keine Controls; und das ist gut so.
Man verwendet entweder eigene HTML Helper oder Partial Views.

Ich kombiniere i.d.R. ASP.NET MVC mit der WebAPI und AngularJS.

• MVC für die Grundstruktur
• WebAPI fürs Laden von einzelnen Elementen bzw. für Aktualisierungen
• AngularJS für die Oberflächenbindung

MVC 5 Buch für MVC 4 reicht völlig. Die Änderungen sind nur marginal.

Hallo Abt,

deinem Blogeintrag nach zu urteilen, stellt die enge Verzahnung des Controllers und die Auswertung der Daten (die meiner Meinung nach ins ViewModel gehören) kein kosmetisches Problem dar.

Es scheint also nach dem ASP.NET MVC Prinzip in Ordnung zu sein, wenn hier keine strikte Logische Code Trennung statt findet?

Ich werde mal schauen in wie aufwendig es sein wird eine Klasse zu schreiben, die sich darum kümmert die HTTP-Get und HTTP-Post Request zu handeln und auf die entsprechenden ViewModels und deren Methoden weiter zu leiten.

Dann entfällt genau dieser unnötige "Zwischenschritt" in dem ein passender Controller erstellt werden muss der dann das jeweilige ViewModel instanziert und deren Methoden und Daten weiterleitet bzw. aufruft.

Sollte eigentlich nicht so schwer sein zu implementieren?

Erst mal gibt es keine Verzahnung zwischen Controller und View, sondern zwischen View und Action; und auch das nur beschränkt:
Eine Action weiß, mit welchen Parametern(SubmitModel) es aufgerufen wurde und welche Views es inne hat - können auch mehrere sein. Eine View weiß aber nicht, von welcher Action sie aufgerufen wurde. Die View wiederum kennt nur ihr ViewModel.

Der Blogeintrag zeigt zudem nur, wie man Daten von der Action sauber an die View gibt, und wie man Daten an der Action (woher auch immer, gibt ja verschiedene Quellen) typisiert entgegen nimmt.
Da steckt keine Logik dahinter.

Dein Versuch hat nicht wirklich was mit dem MVC Pattern zutun. Daher eher die Frage: sicher, dass Du damit überhaupt arbeiten willst?
Laut meiner Aussage und meinem Blogeintrag gehört ein ViewModel zu einer View und ein SubmitModel zu einer Action - damit arbeite ich so selber ((und wie ich weiß, mittlerweile andere ebenfalls nach diesem Schema)