wake-up-neo.net

Wie organisieren Sie Ihre Projekte?

Haben Sie einen bestimmten Stil für die Organisation von Projekten?

Zum Beispiel erstelle ich gerade ein Projekt für ein paar Schulen hier in Bolivien. So habe ich es organisiert:

TutoMentor (Solution)
TutoMentor.UI   (Winforms project)
TutoMentor.Data (Class library project)

Wie genau organisieren Sie Ihr Projekt? Haben Sie ein Beispiel für etwas, das Sie organisiert haben und auf das Sie stolz sind? Können Sie einen Screenshot des Lösungsfensters freigeben?

Im UI-Bereich meiner Anwendung habe ich Probleme, mich für ein gutes Schema zu entscheiden, um verschiedene Formulare zu organisieren und wo sie hingehören.


Edit :

Was ist mit der Organisation verschiedener Formulare im .UI-Projekt? Wo/wie soll ich verschiedene Formen gruppieren? Es ist eine schlechte Idee, sie alle in die Stammebene des Projekts zu stellen.

150
Sergio

Beim Entwerfen eines Projekts und beim Entwerfen der Architektur gehe ich von zwei Richtungen aus. Zuerst schaue ich mir das Projekt an, das entworfen wird, und bestimme, welche Geschäftsprobleme gelöst werden müssen. Ich schaue mir die Leute an, die es verwenden werden, und beginne mit einem groben UI-Design. An dieser Stelle ignoriere ich die Daten und schaue nur, was die Benutzer verlangen und wer sie verwenden wird.

Sobald ich ein grundlegendes Verständnis dafür habe, wonach sie fragen, bestimme ich, welche Kerndaten sie bearbeiten, und beginne mit einem grundlegenden Datenbanklayout für diese Daten. Dann stelle ich Fragen, um die Geschäftsregeln zu definieren, die die Daten umgeben.

Indem ich unabhängig von beiden Enden ausgehe, kann ich ein Projekt so gestalten, dass die beiden Enden miteinander verschmelzen. Ich versuche immer, die Designs so lange wie möglich getrennt zu halten, bevor ich sie zusammenschmelze, aber denke an die Anforderungen der einzelnen Designs, wenn ich vorwärts gehe.

Sobald ich ein solides Verständnis für jedes Ende des Problems habe, beginne ich, die Struktur des Projekts festzulegen, das zur Lösung des Problems erstellt wird.

Sobald das Grundlayout der Projektlösung erstellt ist, schaue ich mir die Funktionalität des Projekts an und richte einen Basissatz von Namespaces ein, die je nach Art der ausgeführten Arbeit verwendet werden. Dies können Dinge wie Konto, Einkaufswagen, Umfragen usw. sein.

Hier ist das grundlegende Lösungslayout, mit dem ich immer beginne. Wenn die Projekte besser definiert werden, verfeinere ich sie, um den spezifischen Anforderungen jedes Projekts gerecht zu werden. Einige Bereiche können mit anderen zusammengeführt werden, und ich kann nach Bedarf einige spezielle hinzufügen.

SolutionName

.ProjectNameDocuments
    For large projects there are certain documents that need to be kept with
    it. For this I actually create a separate project or folder within the 
    solution to hold them.
.ProjectNameUnitTest
    Unit testing always depends on the project - sometimes it is just really 
    basic to catch Edge cases and sometimes it is set up for full code 
    coverage.  I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
    Some projects have specific installation requirements that need to be 
    handled at a project level.
.ProjectNameClassLibrary
    If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
    I am adding this because I just found a need for one in my current project.  
    This project holds the following types of scripts: SQL (Tables, procs, 
    views), SQL Data update scripts, VBScripts, etc.
.ProjectName
    .DataRepository 
        Contains base data classes and database communication.  Sometimes 
        also hold a directory that contains any SQL procs or other specific 
        code.  
    .DataClasses
        Contains the base classes, structs, and enums that are used in the 
        project.  These may be related to but not necessarily be connected
        to the ones in the data repository.
    .Services 
        Performs all CRUD actions with the Data, done in a way that the 
        repository can be changed out with no need to rewrite any higher 
        level code.
    .Business
        Performs any data calculations or business level data validation,
        does most interaction with the Service layer.
    .Helpers
        I always create a code module that contains helper classes.  These 
        may be extensions on system items, standard validation tools, 
        regular expressions or custom-built items.  
    .UserInterface
        The user interface is built to display and manipulate the data.  
        UI Forms always get organized by functional unit namespace with 
        additional folders for shared forms and custom controls.
109
Amy Patterson

Ich mag es, meine Projekte in Ebenen zu unterteilen

Auf diese Weise ist es einfacher, zyklische Abhängigkeiten zu verwalten. Ich kann garantieren, dass beispielsweise kein Projekt versehentlich das View-Projekt (Layer) importiert. Ich neige auch dazu, meine Schichten in Unterschichten zu brechen. Alle meine Lösungen haben also eine Liste solcher Projekte:

  • Product.Core
  • Product.Model
  • Product.Presenter
  • Produkt.Persistenz
  • Product.UI
  • Product.Validation
  • Product.Report
  • Product.Web

Sie sind die größeren "Bausteine" meiner Anwendung. Dann organisiere ich in jedem Projekt logischer in Namespaces, aber es variiert sehr. Für die Benutzeroberfläche versuche ich beim Erstellen vieler Formulare, in einer räumlichen Unterteilung zu denken und dann Namespaces für jedes "Leerzeichen" zu erstellen. Angenommen, es gibt eine Reihe von Benutzereinstellungen und Formularen für Benutzereinstellungen. Ich hätte einen Namespace namens UserPreferences für sie und so weiter.

69
Alex

Projekte organisieren

Normalerweise versuche ich, meine Projekte nach Namespace aufzuteilen, wie Sie sagen. Jede Ebene einer Anwendung oder Komponente ist ein eigenes Projekt. Wenn es darum geht, wie ich meine Lösung in Projekte aufteile, konzentriere ich mich auf Wiederverwendbarkeit und Abhängigkeiten dieser Projekte. Ich denke darüber nach, wie andere Mitglieder meines Teams das Projekt verwenden werden und ob andere Projekte, die wir später erstellen, von der Verwendung einer Komponente des Systems profitieren können.

Manchmal reicht es beispielsweise aus, nur dieses Projekt zu haben, das über eine ganze Reihe von Frameworks (E-Mail, Protokollierung usw.) verfügt:

MyCompany.Frameworks

In anderen Fällen möchte ich möglicherweise Frameworks in Teile zerlegen, damit sie einzeln importiert werden können:

MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework

Formulare organisieren

Das Organisieren von Formularen unter einem UI-Projekt ändert sich wirklich, wenn Ihr Projekt erweitert wird.

  • Klein - Ein einfacher Ordner Forms kann für ein sehr kleines Projekt ausreichen. Manchmal können Sie Strukturen genauso überarbeiten wie Namespaces und die Dinge viel komplizierter machen, als sie sein müssen.

  • Mittel bis Groß - Hier beginne ich normalerweise, meine Formulare in Funktionsbereiche zu unterteilen. Wenn ich einen Teil meiner App habe, der 3 Formulare zum Verwalten eines Benutzers enthält, und einige, die Fußballspiele und -ergebnisse verfolgen, dann habe ich einen Formulare> Benutzer Bereich und ein = Forms> Games area oder so ähnlich. Es hängt wirklich vom Rest des Projekts ab, wie viele Formen ich habe, wie feinkörnig ich es aufteile.

Denken Sie daran, dass am Ende des Tages Namespaces und Ordner nur dazu da sind, Ihnen zu helfen, Dinge schneller zu organisieren und zu finden.


Es hängt wirklich von Ihrem Team, Ihren Projekten und dem ab, was für Sie einfacher ist. Ich würde vorschlagen, dass Sie im Allgemeinen separate Projekte für jede Schicht/Komponente Ihres Systems erstellen, aber es gibt immer Ausnahmen.

Anleitungen zur Systemarchitektur finden Sie unter Microsoft-Website für Muster und Vorgehensweisen.

19
Ryan Hayes

Wenn ich Code in .NET schreibe, besteht eine klare Tendenz zu Clustern verwandter Funktionen. Jeder von ihnen kann einige Teilmengen derselben haben. Ich mag es, die Hauptgruppen physisch aufzuteilen - eine davon pro VS-Projekt. Ich unterteile dann logisch weiter unter Verwendung von Baugruppen. Nach diesem Muster sieht eines meiner aktuellen Projekte folgendermaßen aus:

  • Wadmt (Lösung)
    • Wadmt.Common
    • Wadmt.Data
      • Wadmt.Data.MySql
      • Wadmt.Data.SqlServer
      • Wadmt.Data.Oracle
    • Wadmt.Domain
    • Wadmt.Services
    • Wadmt.Tests
      • Wadmt.Tests.Common
      • Wadmt.Tests.Domain
      • Wadmt.Tests.Services
      • Wadmt.Tests.Integration
    • Wadmt.Web

Hoffentlich ist das nützlich für Sie. Die Trennungsgrade brauchten einige Zeit, um herauszufinden.

12
Grant Palin

Es ist gut, einen Plan für die Organisation Ihrer Lösungen zu haben, und es gibt verschiedene Möglichkeiten, dies zu tun. Wir haben einige Funktionen, die von mehreren Projekten gemeinsam genutzt werden und die auch unseren Benutzern Konsistenz bieten. Die Projektorganisation hängt davon ab, was wir tun. Im Kern werden wir haben:

Company (solution)
  Company.Common (shared library)
  Company.Project (Main application UI)
  Company.Project.UnitTests (Unit tests for all project modules)
  Company.Project.IntegrationTests (integration tests for all project modules)
  Company.Project.AutomationTests (tests that invoke the UI)

Von dort kommt es wirklich auf das Setup an. Wenn wir sowohl eine Client-Anwendung als auch ein Web-Front-End haben (nützlich zum Sammeln von Nutzungsergebnissen im Klassenzimmer oder bei anderen Recherchen), benötigen wir ein Projekt mit dem gemeinsam genutzten Code (d. H. Den Datenobjekten, die serialisiert werden).

  Company.Project.Model (ORM and business logic layer)
  Company.Project.Webapp (Web frontend/web service layer)
  Company.Project.WebClient (client code for web services)

Bei Bedarf können weitere Teilprojekte hinzugefügt werden. Wie gesagt, es kommt wirklich auf das Projekt an. Einige Projekte sind sehr einfach und benötigen nur Kernelemente. Wir versuchen, die willkürliche Projekttrennung zu bekämpfen, also Teilen durch Schichten macht wirklich Sinn. Die Ebenen werden dadurch definiert, was für Projekte, Lösungen oder Plugins/Erweiterungen gemeinsam genutzt werden muss.

7
Berin Loritsch

Es ist interessant, dass so viele Leute DRY hier nicht berücksichtigen. Es kam einige Male in meinem Leben vor, dass Entwickler Verzeichnisstrukturen erstellt haben, die aus diesem Grund nicht erstellt werden konnten. Behalten Sie den Projektnamen bei out off Lösungs- und Projektverzeichnisse!

Also hier ist mein Weg:

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  

Wenn ich meine Anwendung entwerfe, sehe ich sie immer als Module mit einigen Abhängigkeiten dazwischen. Wenn ich ein Design im Sinn habe, verwende ich eine bottom-up Strategie, um es zu entwickeln. Ich entwickle jedes Modul und dann lasse ich sie zusammenarbeiten.

Nun, diese Module sind Projekte unter meiner Lösung (normalerweise Klassenbibliotheken) ). Jedes Modul hat einen anderen Namespace und ein eigenes Design (enthält Klassen usw.).

Eines dieser Module ist die [~ # ~] GUI [~ # ~] ( Grafische Benutzeroberfläche =).

Ich benutze auch immer ein Revisionskontrolle Tool, um die Änderungen in jedem Projekt zu verfolgen. Ich schlage vor Git . Es ist Open Source, verteilt und kostenlos zu verwenden.

2
Oscar Mederos

Jedes Mal, wenn ich mit einem neuen Projekt beginne, bekomme ich eine umfassende Beschreibung dessen, was es tun soll. Wenn ich diesen Input habe, kann ich einen Kontext bereitstellen. Daher denke ich über die beste (oder am besten geeignete) Methode nach, um die Projektziele zu erreichen. An diesem Punkt beginne ich zu überlegen, in welchen Desgin-Mustern ich die beabsichtigte Lösung finden kann. Hier beginne ich mit der Organisation des Projekts unter Berücksichtigung der Entwurfsmuster, die ich für das Projekt übernehmen werde.

Einige Beispiele:

  1. Wenn sich das Projekt nur auf das Erstellen von Eingabedatenbildschirmen bezieht. Höchstwahrscheinlich würde ich ein MVC-Muster verwenden.
  2. Wenn das Projekt als Hochleistungs-Benutzeroberfläche verwendet werden soll, die die meisten Plattformen mit mehreren Plattformen unterstützt, ist ein MVVM-Entwurfsmuster hilfreich.

Denken Sie daran, dass Sie dadurch gezwungen sind, Ihr Projekt auf eine bestimmte Art und Weise zu organisieren.

Hier ist eine Lektüre für Sie:

. Net Design Patterns .

Entwurfsmuster .

Objektorientiertes Design .

Hoffe das hilft.

1
El Padrino