2016-06-28 8 views
2

Wir haben eine Reihe von kleinen ASP.NET MVC-Anwendungen. Bei allen handelt es sich im Wesentlichen um eine Reihe von Formularen, die Daten erfassen und in einer SQL Server-Datenbank speichern, die normalerweise in unser Datawarehouse geladen und für die Berichterstellung verwendet wird.ASP.NET MVC - Mehrere kleine Apps zusammenführen

Wir wollen alle kleinen Anwendungen neu schreiben und ein gewisses Maß an Konsistenz und guter Praxis anwenden. Alle Anwendungen sind ziemlich ähnlich, und ich denke, aus der Sicht der Benutzer wäre es besser, wenn sie Teil der gleichen großen Anwendung wären. Daher haben wir uns überlegt, sie im Zuge des Neuschreibens zusammenzufassen.

Unsere beiden derzeit bevorzugten Optionen zu sein scheinen:

  1. eine separate Portalanwendung erstellen, die der Nutzer Einstiegspunkt zu den Anwendungen sein wird. Dies könnte "Kacheln" auf der Startseite haben, eine für jede der Apps (die in dieser übergeordneten App registriert wären) und könnte sie mit allen verknüpfen. In diesem Szenario verbleiben alle Apps in verschiedenen Projekten und werden unabhängig voneinander kompiliert/bereitgestellt. Dies scheint den Vorteil zu haben, das Getrennte beizubehalten, so dass wir Änderungen an einer App vornehmen und bereitstellen können, ohne die anderen zu beeinflussen. Ich könnte einfach Code in eine Klassenbibliothek herausziehen? Eine Sache, die mich darüber ärgert, ist, dass die Eltern-App grundsätzlich fest codierte Links verwenden muss, um zu jeder App zu verlinken.

  2. Ich untersuchte "Bereiche" in ASP.NET MVC und habe alle kleinen Apps als verschiedene Bereiche in einem großen Projekt. Dies scheint irgendwie sauberer in meinem Kopf, wie sie alle an einem Ort sind, aber es hat den Nachteil, die gesamte App erfordert, wenn einer der einzelnen geändert werden, und ich habe das Gefühl, wir werden in Schwierigkeiten geraten nach dem Hinzufügen eines Anzahl der Apps im Mix.

  3. Wir haben eine SharePoint-Installation und jemand schlug vor, die Portaltyp-App in SharePoint zu erstellen ... Das klingt für mich nicht nach der besten Idee, aber ich bin bereit zu prüfen, ob jemand Vorteile auf diese Methode hinweisen kann.

Gibt es irgendwelche Empfehlungen zur Architektur? Hat jemand ähnliche Projekte in der Vergangenheit abgeschlossen und etwas hat gut/nicht gut funktioniert?

Wir haben 4 Entwickler und wir erwarten nicht, dass sich die Apps zu sehr verändern, sobald sie einmal entwickelt wurden (außer um mögliche Fehler zu beheben usw.). Wir werden jedoch planen, der Lösung im Laufe der Zeit neue Apps hinzuzufügen.

Danke

Antwort

0

MVC Bereiche Vorteil Code-Sharing würde erlauben, durch die wiederholten redundanten Teile jeden App Refactoring den gleichen Infrastruktur-Code (Sicherheit, Protokollierung, Datenzugriff, etc.)

Aber verwenden Das bedeutet auch mehr Konflikte beim ersten Zusammenführen des Codes.

Probleme bei der Bereitstellung können mit einem fortlaufenden Bereitstellungstool (es gibt viele auf dem Markt) gemindert werden. Wenn Sie die Bereitstellung in einer Azure WebApp vornehmen, können Sie mit Bereitstellungsslots eine Bereitstellung mit null Ausfallzeiten erzielen.