Webanwendungen - kombinieren oder trennen?

Question

Für unser Unternehmen erstelle ich eine große Extranet-Website, die eine Reihe von Unteranwendungen enthalten wird. Ich bin etwas verwirrt, wie die Lösung und die Projekte richtig aufgebaut sein sollten.

Ich habe eine Webanwendung, die wir das Portal nennen. Sie enthält die Authentifizierungs-/Autorisierungsklassen, Masterpages, Navigations- und URL-Routing-Klassen sowie Themendefinitionen. Außerdem enthält sie einige grundlegende Übersichten für unsere Kunden, damit sie sich einen schnellen Überblick über den Projektstatus verschaffen können.

Im kommenden Jahr werden wir weitere Anwendungen entwickeln und in das Portal integrieren. Stellen Sie sich das als detaillierte Übersichten und Werkzeuge vor, die wir Feature A, B und C nennen. Im Laufe der Jahre werden wir diese Anwendungen verbessern und neue Versionen veröffentlichen. Diese Webanwendungen sollen sich nahtlos in die Navigation des Portals einfügen. Ich möchte, dass sie die Masterpages und Themen wiederverwenden.

Wie kann ich diese Lösung richtig einrichten?
Wie kann ich die Anwendungen miteinander verknüpfen, die Stammseiten wiederverwenden und die Wartbarkeit gewährleisten?
Wie kann ich bestimmte Webcontrols (ASCX) auf geeignete Weise freigeben?
Wir verwenden TFS, vielleicht irgendwelche Verzweigungs-/Zusammenführungsideen?

Edit :
Ich würde es gerne in ASP.Net WebForms erstellen, da wir in diesem Bereich die meiste Erfahrung haben. Aber im Grunde können wir alles verwenden, wir haben den Webserver unter unserer eigenen Kontrolle (solange er sich an Microsoft orientiert und nicht zu php oder ähnlichem wechselt :))

Answer 1

Wie Brian sagt, sollte man sich bei der Veröffentlichung einer API so weit wie möglich an sie binden, d.h. sie sollte sich nach der ersten Veröffentlichung so wenig wie möglich ändern. Um etwas so stabil zu machen, muss man jedoch im Vorfeld viel Aufwand betreiben. Wenn man also nicht bereit ist, sich auf die API festzulegen, sollte man sie stattdessen so weit wie möglich verinnerlichen, und aus diesem Grund sollte man Dinge eher kombinieren als trennen.

Ich werde jedoch nicht aufgrund einer Beschreibung in 5 Absätzen eine für Ihre Anwendung geeignete Architektur vorschlagen. Vielmehr müssen Sie die Vor- und Nachteile einiger weniger großer Projekte gegenüber einer Reihe lose gekoppelter kleiner Projekte abwägen. Ich meine, je mehr Planung Sie im Vorfeld betreiben, desto einfacher werden Sie es später haben, vorausgesetzt, Sie halten sich an Ihren Plan.

Im Gegensatz zu Brians Antwort würde ich Ihnen also nicht empfehlen, Ihr gesamtes System "so lose gekoppelt wie möglich" zu machen, sondern nur so lose gekoppelt wie nötig ;) Lose gekoppelter Code kann genauso viel Ärger verursachen wie eng gekoppelter Code, wenn man ihn missbraucht.

Siehe:
1. Was ist besser, viele kleine Baugruppen oder eine große Baugruppe?
2. Spezifische Nachteile vieler "kleiner" Baugruppen?

Letztendlich wissen nur Sie selbst, wie sehr Sie sich auf die einzelnen "...bilities", Wartbarkeit, Erweiterbarkeit, Zuverlässigkeit usw. konzentrieren wollen. Machen Sie sich also Ihre Prioritäten und Ziele klar und planen Sie entsprechend.

Zu den Verzweigungsstrategien können Sie in der TFS-Verzweigungsleitfaden 2.0 die eine gute Einführung in verschiedene Verzweigungsstrategien bieten, die von grundlegend bis fortgeschritten reichen. Auch wenn Sie kein TFS verwenden, ist dies ein guter Leitfaden (ich verwende derzeit SVN). Da ich derzeit in kleinen Teams mit 1-4 Entwicklern arbeite, neige ich dazu, eine Strategie zu verwenden, die zwischen Basis und Standard liegt. Ich empfehle das nicht für Sie, aber für unser Team funktioniert das am besten.

Was die gemeinsame Nutzung von Code zwischen Projekten angeht. In SVN können wir " Externe "Das bedeutet, dass die freigegebene Datei in mehreren Ordnern erscheint. Wenn Sie also eine Kopie ändern und die Änderung an svn übergeben, werden alle anderen Kopien beim nächsten svn-Update aktualisiert. Ich kann mich jedoch nicht erinnern, ob TFS etwas Ähnliches bietet.

Anmerkung: Hüten Sie sich vor Externals in SVN... sie können... Probleme verursachen. ;)

Mein Rat ist, die gemeinsame Nutzung von aspx-, ascx- und Masterseiten so weit wie möglich zu vermeiden. Das schadet in der Regel mehr, als dass es hilft. Versuchen Sie stattdessen, Vererbung oder andere Alternativen zu verwenden, um Ihr Ziel zu erreichen.

ASP.NET MVC 2.0 verfügt über ein Konzept namens "Areas", bei dem Sie Unterabschnitte einer Anwendung isoliert vom Rest erstellen. Soweit ich weiß, können diese Bereiche in separaten Projekten von der "Hauptanwendung" gepflegt werden. Es klingt sehr ähnlich wie das, was Sie beantragen, so dass Sie vielleicht in das aussehen sollte.

Ich hoffe, es macht Sinn ;)

Answer 2

What is the proper way to setup this solution?

Der richtige Weg... Es gibt so viele. Ich habe viele Bewerbungen gesehen, und eine Menge von verschiedene Setups (von denen ich viele als "richtig" bezeichnen würde). Was Sie wirklich fragen, ist der beste Weg für Ihre Situation.

Da es sich um ein Portal handelt, haben Sie den Luxus, die Funktionen zu trennen, was Ihnen bei der Entwicklung zusätzlicher Funktionen für Ihre Anwendung helfen wird.

Ich würde eine einzige Website mit einem separaten Ordner für jede Funktion einrichten. Wenn Sie eine einzige Website erstellen, können alle Funktionen dieselben Masterpages, Benutzerkontrollen und Konfigurationsdateien verwenden, ohne dass Sie etwas Besonderes tun müssen. (In diesem Sinne würde ich alle Masterseiten in einen eigenen Ordner legen und einen weiteren Ordner für die Benutzersteuerung erstellen).

How can I tie the applications together, re-use the master pages and keep it maintainable?

Nochmals: Ordner sind hier die beste Option. Ordner helfen dabei, die einzelnen Funktionen voneinander zu trennen, so dass die Anwendung leicht zu verwalten ist.

How can I share certain webcontrols (ASCX) in a proper way?

Zunächst einmal sind ascx-Dateien keine Webcontrols. Sie sind Benutzersteuerelemente. WebControl ist eine Klasse zur Erstellung von Server-Steuerelementen, die sich in einer separaten Assembly befinden. Was die Benutzersteuerelemente betrifft, so sind sie, wie gesagt, immer an einem Ort und in der gesamten Anwendung verfügbar, wenn Sie sie in einen separaten Ordner legen.

We are using TFS, perhaps any branching/merging ideas?

Es gibt eigentlich nichts Besonderes, was Sie hier tun müssen. Es gibt viele verschiedene Wege, die Sie bei der Verzweigung einschlagen können:

• Eine davon ist, für jede Version einen Zweig zu erstellen.
• Eine andere Möglichkeit besteht darin, für jede neue Funktion, die Sie hinzufügen, einen Zweig zu erstellen (in Ihrem Fall ist das so ziemlich dasselbe wie die erste Option).
• Eine weitere Möglichkeit besteht darin, für jeden Entwickler einen eigenen Zweig zu erstellen.

Wenn ich entscheide, wie ich meinen Code verzweigen will, überlege ich, was mich am meisten schützt. In Ihrem Fall müssen Sie Fehlerkorrekturen zwischen den Funktionsversionen einplanen, so dass vielleicht eine Verzweigung nach jeder Version am sinnvollsten ist (nennen Sie es Ihren Entwicklungszweig). Angesichts der Trennung der Funktionen, kann es jedoch sein, dass eine Funktion keine Auswirkungen auf den Rest der Anwendung hat. Sie brauchen diese Art von Verzweigung vielleicht nicht, um sicher zu sein.

Answer 3

Ich würde mir überlegen, Ihr System als lose gekoppelt wie möglich. Wenn Sie weitere Anwendungen hinzufügen, wird Ihre Website immer unzuverlässiger (da keine Komponente 100 % der Zeit verfügbar ist und die Kombination dieser Komponenten die Gesamtzuverlässigkeit verringert). Daher sollten Sie Ihr System so aufbauen, dass es auch für den Fall eines Ausfalls der nicht so wichtigen Dienste gerüstet ist (ich glaube, die Amazon-Homepage beispielsweise hat etwa 100 Dienste, die zu ihr beitragen, und ist daher auf Fehlertoleranz ausgelegt).

Ihre APIs zwischen den Diensten sollten so stabil wie möglich bleiben, so dass sich die Implementierungen ändern können, ohne die Kopplung zu unterbrechen. Sie sollten auch automatisierte Tests auf der Web-Ebene untersuchen (vielleicht Selen oder ähnliches?), da das Testen der einzelnen Dienste nur wenig Aufschluss über das Gesamtverhalten gibt.

Answer 4

Es könnte nützlich sein, die Implementierung einer benutzerdefinierten VirtualPathProvider . In meinem letzten Projekt hatten wir mehrere ASP.NET-Websites, die Themadateien (Masterseiten, Benutzersteuerelemente, Bilder, Stylesheets) gemeinsam nutzen mussten. Daher habe ich einen VirtualPathProvider erstellt, mit dem wir einen virtuellen Ordner (z. B. /Themes) einem beliebigen physischen Ordner auf der Festplatte zuordnen konnten (z. B. C:\Shared\SiteThemes ).

Es ist nicht trivial, aber es hat nicht allzu lange gedauert und keine Probleme verursacht. Es hat sich übrigens als eine gute Möglichkeit erwiesen, die maximale Komponentenbegrenzung in WiX zu überwinden... Beachten Sie, dass Sie Sites, die einen VirtualPathProvider verwenden, nicht vorkompilieren können.

Answer 5

Verwenden Sie ab jetzt MVC-Konzepte. Sie bieten mehr Erweiterbarkeit und Flexibilität für robuste Anwendungen.