Wie strukturiert man ein Projekt am besten?[geschlossen]

Question

Ich habe mich gefragt, wie ich meine Projekte strukturieren sollte.

Wir haben einige Projekte, die in anderen Projekten (wieder)verwendet werden.

Ich meine, unser Datenprojekt und unser Modellprojekt werden in mehreren anderen Projekten verwendet.

Was ich wirklich wissen muss, ist, wie man ein Projekt dieser Art strukturiert und wie man es am besten benennt.

In einer standardmäßigen 3-Tier-Anwendung sollte dies etwa so aussehen:

1. DAL, DataAccessLayer, Daten ...
2. Modell, BusinessObject, BOL ...
3. Benutzeroberfläche, Ansicht, ...

Irgendwelche anderen Ideen?

In jedem Unternehmen, in dem ich arbeite, gibt es unterschiedliche Organisationsmethoden. Gibt es eine bessere als die andere?Welches verwenden Sie und welches bevorzugen Sie und warum?

Danke!

Answer 1

Für die Datenschicht verwende ich normalerweise:

Company.ProjectName.Data (d. h.AdventureWorks.OrderManager.Data)

Für die Business-Schicht bevorzuge ich etwas wie „ObjectModel“ (ich habe „Business“ oder „BusinessLogic“ verwendet, aber das ist der Bereich, in dem Daten in Objekten/Klassen zusammenkommen, warum also nicht so nennen?).

Company.ProjectName.ObjectModel (d. h.AdventureWorks.OrderManager.ObjectModel)

Was die Benutzeroberfläche betrifft, mag ich entweder die einfache alte „Benutzeroberfläche“ oder „Präsentation“ ...

Firma.Projektname.Präsentation (d. h.AdventureWorks.OrderManager.Presentation)

Answer 2

Das ist ziemlich viel, was ich tun, außer ive bekam ein paar Bibliothek Projekte, bei denen ich versuche, meinen alle wieder verwendbaren Code zu setzen. Dann lehnen Sie sich mein Modell und DAL auf dieser librarys, nur das Hinzufügen Projektspezifika zu ihnen

Answer 3

Meistens benutze ich geschichtete Architektur wie in Microsoft Patterns empfohlen & Practices Application Architecture für .NET: Entwerfen von Anwendungen und Dienste . Dokument beschreibt die Architektur und .NET-Technologien, sie umzusetzen.

Answer 4

Die Software-Architektur ist abhängig von der Art der Software zu bauen. Wenn Sie andere Programmier Kernel wollen Prinzipien tun, gelten im Vergleich zu Anwendungsentwicklung zu tun. Doch gelten andere Grundsätze, wenn die physikalische Simulation, Wetter-Prognose-Software, Software-IDE oder Compiler tun werden.

Ich nehme an, Sie Anwendungsentwicklung machen wollen. Nun, dann werden Sie wahrscheinlich wollen, um Ihre Software zu entwerfen, um die Domain, die Sie reflektieren werden. Aber selbst dann gibt es viele Möglichkeiten.

Für mehr Einsicht in diesem großen Thema, empfehle ich Domain Driven Design von Eric Evans und Applying Domain-Driven Design and Patterns von Jimmmy Nilsson zu lesen.

Answer 5

Im Moment arbeite ich auf Front-End-Web-Anwendung, die eine 3-Tier-Architektur hat:

• Client-Schicht (der Browser)
• Anwendungsschicht (Java EE-Anwendungsserver, auf dem die Anwendung lebt)
• Backend-Tier (Mainframe- und Legacy-Anwendungen, verschiedene Datenbanken)

Es hat eine geschichtete Architektur, und die Schichten in der Anwendungsebene sind:

• Präsentationsschicht: erzeugt die Benutzeroberfläche, die in der Client-Schicht verwendet werden
• Anwendungsschicht: das Äquivalent von Anwendungsfällen, enthält die Anwendungslogik
• Service Schicht: Karten Domain-Logik und Daten aus Backend-Tiere auf ein Java-Modell
• Integrationsschicht: kommuniziert mit dem Backend-Tiere und enthält Gateways für JMS, E-Mail, ... und DAOs und andere Sachen

Dies ist nur ein Beispiel Projektstruktur, und das Endergebnis wird von der Art der Anwendung ab. Mehr erfahren Sie in meine Antwort diese Frage über die Aufteilung und Namensstrategie für Pakete.

Sie können hinzufügen / swap / entfernen Schichten, wie Sie sehen, passen. In einer SOA zum Beispiel können Sie eine Webservice-Schicht auf der Anwendungsschicht oder Service-Schicht-Schicht, so dass der ESB (Enterprise Service Bus) für Ihre Anwendung oder Dienstleistungen verbinden kann. Wenn einer das nicht möglich ist, oder scheint sehr schwierig, Sie nicht über eine optimale Architektur und Design haben.

Wenn Sie die Struktur Ihres Projekts zu denken und über Szenarien wie das zu ermöglichen, einige wichtige Eigenschaften der Module und Komponenten, die Sie wollen, sind:

• Testbarkeit
• Reusability
• Wartbarkeit

Sie können dies erreichen, für eine geringe Kopplung und hohe Kohäsion durch die Gestaltung. eine geschichtete Architektur der Auswahl von Modulen durch die Ebene der Funktionalität / Abstraktion Gruppierung ist ein guter Anfang. Innerhalb jeder Schicht durch Funktionalität hilft auch die Gruppierung weiter. Lassen sich spezifischere Schicht hängen nur von Schnittstellen einer allgemeineren Ebene reduziert zu Kupplung.