Ich entschuldige mich dafür, dass ich eine solche allgemeine 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.
Ich schätze, ich gebe Ihnen nicht genug Details, um weiterzumachen, haben Sie irgendwelche Ressourcen oder Ratschläge, wie Sie Ihre Domains logisch aufteilen können ? Für den Fall, dass dies hilfreich ist, werden die meisten dieser Funktionen über Webservices bereitgestellt, und wir sind ein Microsoft Shop mit all den neuesten Gadgets und Gadgets.
OurCRMProduct.Customer gegenüber einer generischen Klasse Customer )? BAL und DAL haben, oder sollte das eine komplett separate Assembly sein, auf die alles verweist? Ich habe keine Erfahrung mit der Organisation solcher weit reichenden Projekte, nur Einzelstücke, also suche ich nach einer Anleitung, die ich bekommen kann.
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.
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 Ihre Assemblies nach 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.
Mein Rat, nach einer ähnlichen Unternehmung, besteht darin, sich nicht um die Namensräume zu quälen.
Beginnen Sie einfach mit ein paar wichtigen, losen Richtlinien zu entwickeln, denn wie auch immer Sie beginnen, Ihr Projekt ist organisch, und Sie werden am Ende die Namensräume und Klassen im Laufe der Zeit reorganisieren.
Verschwenden Sie keine Zeit damit, zu viel über Ihr Projekt zu reden. Mach es einfach.
Wir nennen die Assemblys in .NET folgendermaßen: Company.Project.XXXX.YYYY Dabei steht XXXX für Project und YYYYY für das Subprojekt, zum Beispiel:
Wir nehmen das aus einem Buchanruf Framework Design Guidelines von Krzysztof Cwalina (Autor), Brad Abrams (Autor )
Ich habe kürzlich genau das gleiche bei der Arbeit erlebt. Viel Ad-hoc-Code, der strukturiert und organisiert werden musste.
Zuerst ist es echt schwer, da es so viel gibt. Ich denke, der beste Rat, den ich geben könnte, ist, einfach an einem Freitagnachmittag Zeit zu investieren. Ich würde für ein paar Wochen einfach eine App / einen Block Code auswählen und untersuchen, was war Denke darüber nach, was wir generisch machen könnten, kopiere es, lege es in die neue Bibliothek, 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 ein Deal.
Stück für Stück, das ist der einzige Weg, es zu tun.
In Bezug auf die Struktur habe ich versucht, den MS Namespacing irgendwie nachzuahmen, da es größtenteils ziemlich logisch ist (zB Company.Data , Company.Web , < em> Company.Web.UI und so weiter.
Einer der größten Vorteile ist wahrscheinlich die Menge des entfernten Codes. Ja, ein wenig Refactoring war in den Apps erforderlich, aber die Codebasis ist viel schlanker und in vielerlei Hinsicht "intelligenter".
Eine andere Sache, die mir auffiel, ist, dass ich oft Probleme haben würde, wo zu finden, um Sachen (in Bezug auf Namespacing) zu setzen, da ich nicht sicher war, wozu es gehörte. Nun, diese wirklich beunruhigte mich, ich betrachtete es als einen so schlechten Geruch. Seit der Re-org fällt nun alles viel schöner in den Weltraum. Und mit der (jetzt sehr kleinen) Menge an anwendungsspezifischem Code werden sie in Company.Applications.ApplicationName eingefügt. Dies hilft mir, viel mehr über Business-Objekte nachzudenken, da ich nicht zu viel in diesem Namensraum haben möchte Also habe ich flexiblere Designs.
Entschuldigung für die lange Post. Es ist eine Art von Wandern!
Bei großen Projekten möchte ich einen Domain-Namespace für meine Business-Objekte verwenden und dann Data Transfer Objects (DTOs) in meinen Layern 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:
Tags und Links namespaces architecture legacy module