Namensraum/Lösungsstruktur

Question

Ich entschuldige mich dafür, dass ich so eine verallgemeinerte Frage gestellt habe, aber es ist etwas, das mich herausfordern kann. Mein Team ist dabei, ein großes Projekt zu starten, das hoffentlich alle zufälligen, einmaligen Codebasen, die sich über die Jahre entwickelt haben, zusammenziehen wird. Angesichts der Tatsache, dass dieses Projekt die Standardisierung logischer Entitäten im gesamten Unternehmen ("Kunde", "Mitarbeiter"), kleine Aufgaben, große Aufgaben, die die kleinen Aufgaben steuern, und Utility - Services, habe ich Schwierigkeiten, den besten Weg zu strukturieren Namespaces und Codestruktur.

Obwohl ich denke, ich gebe Ihnen nicht genug Details, um fortzufahren, haben Sie irgendwelche Ressourcen oder Ratschläge, wie Sie Ihre Domains logischerweise logisch? Falls es hilft, werden die meisten dieser Funktionen über Web-Services enthüllt und wir sind ein Microsoft Shop mit all den neuesten Gizmos und Gadgets.

Ich diskutiere eine massive Lösung mit Teilprojekten, um Referenzen einfacher zu machen, aber wird es das zu unhandlich machen?

Sollte ich Legacy-Anwendungsfunktionalität einpacken, oder lassen Sie das völlig agnostisch im Namensraum (zum Beispiel eine OurCRMProduct.Customer Klasse im Vergleich zu einer generischen Customer Klasse)?

Sollte jeder Service/Projekt eigene BAL und DAL haben, oder sollte das eine komplett separate Baugruppe sein, auf die alles verweist?

Ich habe keine Erfahrung mit der Organisation von so weit reichenden Projekten, nur einmalige, also suche ich nach einer Anleitung, die ich bekommen kann.

Answer 1

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

Zuerst reduzieren Sie 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 für die Erweiterbarkeit konzipiert ist, sollten Sie Ihre Assemblies nach den Gesichtspunkten Design und Implementierung aufteilen. Platzieren Sie Ihre Schnittstellen und Basisklassen in einer öffentlichen Assembly. Erstellen Sie eine Assembly für die Implementierung dieser Klassen in Ihrem Unternehmen.

Bei großen Anwendungen sollten Sie Ihre Benutzeroberflächenlogik und Geschäftslogik getrennt halten.

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

Answer 2

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

Es ist wirklich schwer zuerst, da es so viel gibt. Ich denke, der beste Rat, den ich geben könnte, ist nur investieren Zeit in es auf den Wind an einem Freitagnachmittag, für ein paar Wochen würde ich nur eine App/Stück Code auswählen, untersuchen, was da war, darüber nachdenken wir könnten es generisch machen, es kopieren, es in die neue Bibliothek stellen, wo auch immer ich es dachte. Sobald ich den gesamten Code innerhalb einer Anwendung migriert hatte, würde ich dann daran arbeiten, die Anwendung so zu refactorisieren, dass sie vom allgemeinen Framework aus funktioniert. Dies verursachte manchmal Probleme, die behoben werden mussten, aber solange Ihr Programm nicht zu groß sein sollte eine Abmachung.

Stück für Stück, das ist der einzige Weg, es zu tun.

In Bezug auf die Struktur, habe ich versucht, da zum größten Teil Art seiner ziemlich logisch, die MS Namespacing nachahmen (zB Company.Data, Company.Web, Company.Web.UI und so weiter .

einer der wichtigsten Vorteile ist wahrscheinlich die Menge an Code Betrogene entfernt. Ja ein wenig Refactoring in den Anwendungen erforderlich war, aber die Code-Basis viel schlanker, und in vielerlei Hinsicht „intelligente“.

ist Eine andere Sache, die ich bemerkte, ist, dass ich oft Probleme haben würde, herauszufinden, wo Dinge (in Bezug auf Namespacing) zu setzen, da ich nicht sicher war, was es gehörte. Jetzt diese wirklich besorgt mich, ich sah es als so ein schlechter Geruch. Seit der Re-org fällt nun alles viel schöner in den Weltraum. Und mit der (jetzt sehr kleinen Menge) von applikationsspezifischem Code, werden sie in Company.Applications.ApplicationName gesetzt Dies hilft mir, wirklich über Geschäftsobjekte viel mehr nachzudenken, da ich nicht zu viel in diesem Namensraum will, also komme ich hoch mit flexibleren Designs.

Sorry für die lange Post .. Es ist eine Art von Wandern!

Answer 3

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

Ich habe oft Unit Test Assemblies in der gleichen Lösung wie die, die sie testen, da Sie dazu neigen, Änderungen an ihnen vorzunehmen.

Answer 4

Wir nennen die Baugruppen in .NET die folgende Art und Weise Company.Project.XXXX.YYYY XXXX steht für Projekt- und YYYYY ist Teilprojekt, zum Beispiel:

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

Wir diese Framework Design Guidelines von Krzysztof Cwalina (Autor), Brad Abrams (Autor)

aus einem Buch Anruf nehmen

Answer 5

Für große Projekte ist der Ansatz, den ich gerne habe, einen Domain-Namespace für meine Geschäftsobjekte zu haben und dann Data Transfer Objects (DTOs) in meinen Layern zu verwenden, wo das Business-Objekt gespeichert und abgerufen werden muss. 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

Answer 6

Mein Rat, auf einem ähnlichen Unternehmen in Angriff genommen haben, ist nicht über die Namensräume auf den Kopf zerbrechen ..

Starten Sie einfach mit der Entwicklung ein paar wichtige lose Richtlinien, denn wie auch immer Sie beginnen, Ihr Projekt ist organisch, und Sie werden am Ende Reorganisation der Namen Räume und Klassen im Laufe der Zeit.

Verschwenden Sie keine Zeit damit, zu viel über Ihr Projekt zu sprechen. Mach es einfach.