Namespace-/Lösungsstruktur

StackOverflow https://stackoverflow.com/questions/12243

Frage

Es tut mir leid, dass ich eine so allgemeine Frage stelle, aber das kann für mich eine Herausforderung sein.Mein Team ist dabei, ein großes Projekt in Angriff zu nehmen, das hoffentlich alle zufälligen einmaligen Codebasen zusammenführen wird, die sich im Laufe der Jahre entwickelt haben.Angesichts der Tatsache, dass dieses Projekt die Standardisierung logischer Einheiten im gesamten Unternehmen („Kunde“, „Mitarbeiter“), kleine Aufgaben, große Aufgaben, die die kleinen Aufgaben steuern, und Versorgungsdienste abdeckt, fällt es mir schwer, herauszufinden, wie ich diese am besten strukturieren kann Namespaces und Codestruktur.

Obwohl ich denke, dass ich Ihnen nicht genügend Einzelheiten gebe, um fortzufahren, Haben Sie Ressourcen oder Ratschläge, wie Sie die logische Aufteilung Ihrer Domains angehen können??Falls es hilft, werden die meisten dieser Funktionen über Webdienste verfügbar gemacht, und wir sind einer Microsoft Shoppen Sie mit den neuesten Gadgets und Gadgets.

  • Ich diskutiere eine umfassende Lösung mit Teilprojekten, um Referenzen einfacher zu machen, aber wird es dadurch zu unhandlich?
  • Soll ich die Funktionalität der Legacy-Anwendung abschließen oder diese völlig agnostisch im Namespace belassen (durch Erstellen einer OurCRMProduct.Customer Klasse versus ein Generikum Customer Klasse zum Beispiel)?
  • Sollte jeder Dienst/jedes Projekt seinen eigenen haben? BAL Und DAL, oder sollte das eine völlig separate Assembly sein, auf die alles verweist?

Ich habe keine Erfahrung mit der Organisation solch weitreichender Projekte, es sind nur Einzelprojekte, daher suche ich nach einer Anleitung, die ich bekommen kann.

War es hilfreich?

Lösung

Es gibt eine Million Möglichkeiten, eine Katze zu häuten.Allerdings ist das Einfachste immer das Beste.Welcher Weg ist für Sie der einfachste?Hängt von Ihren Anforderungen ab.Aber es gibt einige allgemeine Faustregeln, die ich befolge.

Reduzieren Sie zunächst die Gesamtzahl der Projekte so weit wie möglich.Wenn Sie zwanzig Mal am Tag kompilieren, summiert sich diese zusätzliche Minute.

Wenn Ihre App auf Erweiterbarkeit ausgelegt ist, sollten Sie eine Aufteilung Ihrer Baugruppen nach den Gesichtspunkten Design vs.Implementierung.Platzieren Sie Ihre Schnittstellen und Basisklassen in einer öffentlichen Assembly.Erstellen Sie eine Assembly für die Implementierungen dieser Klassen in Ihrem Unternehmen.

Halten Sie bei großen Anwendungen Ihre UI-Logik und Ihre Geschäftslogik getrennt.

Vereinfachen Sie Ihre Lösung.Wenn es zu komplex aussieht, ist es das wahrscheinlich auch.Kombinieren, reduzieren.

Andere Tipps

Nachdem ich ein ähnliches Unterfangen begonnen habe, rate ich Ihnen, sich nicht über die Namensräume den Kopf zu zerbrechen.

Beginnen Sie die Entwicklung einfach mit ein paar wichtigen, losen Richtlinien, denn wie auch immer Sie beginnen, Ihr Projekt ist organisch und Sie selbst Wille Dies führt letztendlich dazu, dass die Namensräume und Klassen im Laufe der Zeit neu organisiert werden.

Verschwenden Sie keine Zeit damit, zu viel über Ihr Projekt zu reden.Tun Sie es einfach.

Ich habe kürzlich genau das Gleiche bei der Arbeit erlebt.Viel Ad-hoc-Code, der strukturiert und organisiert werden musste.

Am Anfang ist es wirklich schwierig, da es so viel gibt.Ich denke, der beste Rat, den ich geben kann, ist einfach Investieren Sie Zeit darin Am Ende eines Freitagnachmittags wählte ich ein paar Wochen lang einfach eine App/einen Codeblock aus, untersuchte, was da war, überlegte, was wir generisch machen könnten, kopierte es und fügte es in die neue Bibliothek ein, wo immer ich wollte es sollte sein.Sobald ich den gesamten Code innerhalb einer Anwendung migriert hatte, arbeitete ich daran, die Anwendung so umzugestalten, dass sie mit dem gemeinsamen Framework funktioniert.Dies verursachte manchmal Probleme, die behoben werden mussten, aber solange Sie gründlich vorgehen, sollte es keine allzu große Sache sein.

Stück für Stück, nur so geht es.

In Bezug auf die Struktur habe ich versucht, den MS-Namensraum irgendwie nachzuahmen, da er größtenteils ziemlich logisch ist (z. B. Firmen Daten , Unternehmen.Web , Company.Web.UI und so weiter.

Einer der größten Vorteile ist wahrscheinlich die Menge an entferntem Code-Dupe.Ja, bei den Apps war eine kleine Umgestaltung erforderlich, aber die Codebasis ist viel schlanker und in vielerlei Hinsicht „intelligenter“.

Eine andere Sache, die mir aufgefallen ist, ist, dass ich oft Probleme hatte, es herauszufinden Wo um Dinge zu platzieren (in Bezug auf den Namensraum), da ich nicht sicher war, wozu sie gehörten.Jetzt das Wirklich Ich beunruhigte mich, ich empfand es als einen so üblen Geruch.Seit der Neuorganisation passt nun alles viel besser in den Weltraum.Und mit der (jetzt sehr geringen Menge) an anwendungsspezifischem Code werden sie eingefügt Company.Applications.ApplicationName Das hilft mir, wirklich viel mehr über Geschäftsobjekte nachzudenken, da ich nicht zu viel in diesem Namensraum haben möchte, sodass ich flexiblere Designs entwickeln kann.

Sorry für den langen Beitrag..Es ist eine Art Geschwafel!

Wir benennen die Assemblys in .NET wie folgt: Company.Project.XXXX.YYYY, wobei XXXX für Projekt und YYYYY für Unterprojekt steht, zum Beispiel:

  • LCP.AdmCom.Common
  • LCP.AdmCom.BusinessObjects
  • LCP.AdmCom.Common.Dal

Das entnehmen wir einem Buchaufruf Richtlinien für das Framework-Design von Krzysztof Cwalina (Autor), Brad Abrams (Autor)

Bei großen Projekten verfolge ich gerne den Ansatz, einen Domänen-Namespace für meine Geschäftsobjekte zu haben und dann Data Transfer Objects (DTOs) in meinen Schichten zu verwenden, wo die Speicherung und der Abruf des Geschäftsobjekts erforderlich sind.Ein DTO ist ein einfaches Objekt, das keine Geschäftslogik enthält.

Hier ist ein Link, der ein DTO erklärt:

http://martinfowler.com/eaaCatalog/dataTransferObject.html

Große Lösungen mit vielen Projekten können recht langsam kompiliert werden, sind aber gemeinsam einfacher zu verwalten.

Ich habe häufig Unit-Test-Assemblys in derselben Lösung wie die, die sie testen, da man dazu neigt, gemeinsam Änderungen an ihnen vorzunehmen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top