Best Practices für zusammengesetzte ASP.NET MVC Web-Anwendungen (MEF, Bereiche, DI)

Question

Ich bin derzeit herauszufinden, wie die Architektur einer vorhandenen nicht sehr modularen ASP.NET MVC 3.0-Anwendung umstrukturieren. Ich habe eine pluginartige Struktur im Sinn, um das bestehende Projekt erweiterbar zu machen.

Ich habe nach verschiedenen Strategien gesucht, um modulare Web-Anwendungen zu machen, und folgendes gefunden. Ich möchte, dass Sie diese Ideen kommentieren.

• MVC Bereiche in separaten Projekten

I Für jedes Plugin eine einzelne ASP.NET MVC-Projekt erstellen möchten, die Controller, Ansichten und Ansichtsmodelle für das Plugin enthält. Ein "Mitarbeiter" -Modul würde einen Bereich zum Auflisten, Erstellen, Aktualisieren und Löschen von Mitarbeitern enthalten. Das klingt jedoch gut, AreaRegistration erforderlich, um alle Bereiche in das Verzeichnis "bin" zu platzieren. Ich fand einen Weg, um meine Umgebung Projekte direkt in den Bereichen Ordner platzieren und die Umgebung Baugruppen aus dem „/ Regionen/[areaname]/bin“ -Ordner zu beheben:

BuildManager.AddReferencedAssembly.Add(Assembly.LoadFrom(…)); 
AppDomain.CurrentDomain.AssemblyResolve += ResolveAssemblies; 

Dies ist recht gut funktioniert und erlaubt es mir, zu implementieren Plugins im Ordner Areas des Hauptprojekts. Ich mag, dass ich die Areas-Funktion verwende, die von ASP.NET MVC standardmäßig bereitgestellt wird.

• MVC Tragbare Areas (MVCContrib)

http://elegantcode.com/2012/04/06/mvc-portable-areas/

Tragbare Bereiche scheinen nicht ein guter Ansatz zu sein, da sie verlangen, dass die Ansichten als eingebettete Ressourcen in der Umgebung Projekt kompiliert werden Datei. Dies würde das Zwischenspeichern von IIS verhindern. Auf der anderen Seite kann ich mir wirklich nicht vorstellen, wie groß der Performance-Nachteil wirklich ist.

• MVC-Module MEF mit

http://www.fidelitydesign.net/?p=104

Um vertrauen auf MEF ich stark lose gekoppelte Dienste in anderen Projekten zu erstellen. Daher dachte ich, es wäre eine gute Idee, es zu verwenden, um ASP.NET MVC Module/Plugins zu entdecken. Ich würde am Ende eine ControllerFactory verwenden, die exportierte Controller mithilfe des Attributs "Export" instanziieren würde. Auf diese Weise hätte ich volle Kontrolle über die Instanziierung des Plugins und könnte MEF verwenden, um Dienste zu erhalten. Die Verwendung von MEF erfordert jedoch viel mehr Arbeit als die Verwendung von MVC-Bereichen, die Controller von Anfang an auflösen.

• Entity Framework über Plugin

Ein Problem, Projekte, ich war nicht in der Lage, so weit zu lösen, ist, wie die Einheiten auf die einzelnen Plug-Projekte zu verteilen. Momentan verwenden wir einen Database First-Ansatz, der aus einer * .edmx-Modelldatei besteht, die alle Entitäten enthält. Selbst mit DbContext oder Code First ist es nicht möglich, mehrere DbContext-Klassen für eine Datenbank zu verwenden. Eine Idee wäre, MEF zu verwenden, um Entitäten von verschiedenen Plugins in eine zentrale DbContext-Klasse zu laden. Ich weiß jedoch nicht, ob dies eine unterstützte und/oder empfohlene Einrichtung ist.

Answer 1

Eine andere Möglichkeit ist die Verwendung meines Griffin.MvcContrib. Es kümmert sich um alle Rohrleitungen für Sie und ermöglicht es Ihnen, Ansichten zu schreiben und Bereiche mit wenig Codeänderungen zu verwenden.

Verwenden Sie es zusammen mit einem IoC-Container, um ein leistungsstarkes Plugin-System zu erhalten. Hier

ist ein Artikel, der zeigt, wie: http://www.codeproject.com/Articles/386674/ASP-NET-MVC-3-plug-in-architecture-using-Griffin-M