Ich schreibe diese Frage vom Standpunkt einer ASP.NET-Anwendung. Ich weiß jedoch, dass es auch für andere Kontexte geeignet sein könnte.
Es gibt so viele Ansätze, um die gemeinsamen Elemente einer ASP.NET-Website zu entwickeln. Hier sind ein paar, denen ich begegnet bin:
Ich betrachte mich selbst nicht als Expertenentwickler, verstehe jedoch gängige OOP-Techniken gut und kann alle meine Projekte gut überstehen. Ich habe jedoch Probleme damit zu wissen, wie man eine Site "gestaltet". Damit meine ich, sollte ich verwenden n-Tier-Architektur ? Ist das immer noch der Goldstandard und die oben genannten Tools nutzen nur dieses Konzept? Ich bin mir ziemlich sicher, dass ich MVC bis zu einer zukünftigen (oder endgültigen) Veröffentlichung aufhalten möchte.
***** Edit: Ich habe den Teil der Frage entfernt, der sich mit Mustern beschäftigt (Singleton, Fabrik), nachdem ich die Trennung der Frage besser verstanden habe. Danke für alle, die diesen Teil bisher beantwortet haben, mein Schwerpunkt liegt jedoch auf dem Architekturteil. *****
Edit # 2: Ich habe den Titel geändert, um eher eine agnostische Frage zu sein, wenn ich feststelle, dass dies für mehr als webspezifische Architektur gelten würde.
Frage: Welche Schritte unternehme ich als ersten Schritt, wenn ich mich vor einer leeren Arbeitsfläche (Lösungsdatei) mit all meinen vorgefertigten Dokumentations- und Systemvoraussetzungen hingelegt habe? Wohin gehe ich von dort?
Ich denke, jede der von Ihnen skizzierten Methoden hat ihre Vorzüge und ihre Nachteile. Was Sie wählen, hängt von Ihren persönlichen Vorlieben, den Erfahrungen Ihrer Mitarbeiter und der Art des Projekts ab - Linq2Sql ist ideal, um schnell einsatzbereit zu sein, ist aber möglicherweise nicht optimal für ein großes und / oder komplexes Unternehmensprojekt geeignet .. das Beste, was Sie dort tun können, ist ein paar zu versuchen und sie kennen zu lernen.
Bei Mustern helfen sie, bestimmte und wiederkehrende Probleme in bewährter Weise zu lösen. Sie erleichtern auch die Einarbeitung für Entwickler, die den Code nicht geschrieben haben. Wie oben, es lohnt sich, ein paar zu versuchen, um ein Gefühl dafür zu bekommen, was sie tun und wann sie zu verwenden sind - aber sie Lösungen für spezifische Probleme der Programmierung anstatt architektonische Muster.
Mein typischer Arbeitsprozess läuft:
Ich würde in der Regel Datenzugriff und Geschäftsobjekte, Geschäftslogik und Präsentation (Website / Winforms) in ihre eigenen Projekte aufteilen, und alles, was ich zu einem späteren Zeitpunkt noch einmal verwenden möchte, wird auch in einem eigenen Projekt verwendet. Ich habe auch ein Basisprojekt, das allgemeine Erweiterungen und Schnittstellen enthält, die ich in fast allem, was ich mache, wiederverwende.
Im Hinblick auf die Architektur versuche ich sicherzustellen, dass meine Projekte lose gekoppelt sind, so dass Sie leicht von einer dreistufigen zu einer n-Tier-Architektur wechseln können. Loose Coupling bedeutet auch, dass Sie den Backing Store wechseln können. Sie müssen lediglich eine neue Datenzugriffsschicht schreiben, wobei der gesamte Logik- und Präsentationscode unverändert bleibt.
Ich denke, es ist wichtig, sich nicht auf drei gegenüber n aufzulockern - wenn Sie Ihre Bedenken trennen, wird das System später nicht auf mehrere Ebenen erweitert sei eine schwierige Übung.
So eine breite (und gute) Frage. Tief durchatmen.
Nicht von Design Patterns zu nehmen, aber sie sind die Taktiken im Vergleich zur Strategie der Architektur. Lerne sie natürlich, aber das ist hier nicht besonders wichtig.
Viele Dinge, die Sie in der Frage erwähnen, schließen sich nicht gegenseitig aus und könnten als Unterstrategien für bestimmte Teile der Gesamtarchitektur betrachtet werden. Meine persönlichen Vorlieben haben sich im Laufe der Zeit und mit der Erfahrung enorm verändert, und ich bin immer noch völlig naiv von einer faszinierenden Technologie, aber ich denke, es gibt nur eine globale Konstante der Architektur:
Trennung von Bedenken .
Dieses Prinzip ist Ihr "Goldstandard", denke ich, der so viele gute Dinge informiert: Unit-Testing, Design by Contract, Dependency Injection, MVC, n-Tier. Ich sage, der erste Schritt ist, SoC zu verstehen, und der zweite ist, mit testgetriebener Entwicklung darauf zu reagieren. Alles andere, was ich denke, hat Vor- und Nachteile, aber die Vorteile von Wartung, Konzeption und einer Architektur, die durch das Erkennen der Probleme vorangetrieben wird, stehen außer Zweifel.
Mein Lesezeichen-Ordner ist nicht das, was ich dachte, aber das sind einige der Online-Beiträge, die meine Meinung zu diesem Thema verfestigt haben:
Bearbeiten: Wo fangen Sie mit der leeren Leinwand an?
Fügen Sie Ihre Einheitentestbibliothek Ihrer Wahl hinzu und skizzieren Sie die Tests (aka Fakten).
Test & gt; Design & gt; Code & gt; Gehe zu 1
Ich persönlich bin ein Fan der n-Tier-Architektur. Wenn ich anfange, erstelle ich in der Regel zwei Projekte für eine Web-Anwendung, die erste für den Business-Logik- und Datenbankzugriff, das ist ein Klassenbibliotheksprojekt. Dann füge ich ein Web-Anwendungsprojekt für die tatsächliche Website hinzu.
Ich habe in der Vergangenheit ein Datenzugriffs-Framework erstellt, das den Microsoft Data Application Block für den gesamten Datenzugriff nutzt, und das verwende ich zur Strukturierung aller Datenanrufe.
Ich habe manchmal Code-Schmied oder andere Gegenstände benutzt, aber bis jetzt habe ich mehr Glück gefunden, nur meinen eigenen Code zu rollen, da ich mit den Daten granularer werden kann. Zugegeben, wenn ich Zeit hätte, andere ORM-Tools zu recherchieren, müsste ich mich vielleicht nicht darum kümmern ...
Ich finde, dass der beste Ansatz in der Regel darin besteht, Ihre Geschäftsobjekte, Datenvalidierung und alle "geschäftlichen" Teile der Anwendung zu erstellen. Programmieren Sie dann die Datenzugriffsblöcke und schließen Sie am Ende alles mit dem Präsentationscode ab. Es erfordert einige Disziplin, um dies zu tun, aber es stellt sicher, dass Sie Dinge auf eine Art und Weise bauen, die wiederverwendet werden kann, und ich hatte großen Erfolg.
Das Buch, auf das Sie verwiesen haben, könnte auch ein gutes Beispiel sein, um damit zu beginnen.
Zusatz von Kommentar
Als Antwort auf einen geschriebenen Kommentar. Normalerweise verwende ich in meiner Business / Data-Klassenbibliothek Namespaces, um die Logik von den Daten zu trennen. Ein paar wichtige Dinge sind hier getan.
Meine Datenmethodenaufrufe sind alle auf die Assembly beschränkt, es handelt sich NICHT um Elemente, die direkt aufgerufen werden können. Auf diese Weise erzwinge ich den Datenzugriff über die Geschäftslogik für alle Präsentationsaufrufe
Alle Dateneingabe und -ausgabe erfolgt über Objekte statt über DataSets oder eine andere Variante
Die Geschäftsmethoden nach der Validierung rufen bestimmte Methoden aus den Datenkomponenten auf, um die benötigten Informationen zu erhalten.
Tags und Links architecture