Welche Überlegungen sollte ich anstellen, bevor Sie eine Anwendung in Visual Studio in mehrere Lösungen aufteilen?

Sie haben also einen Haufen Code und möchten an einem Teil des Codes arbeiten, ohne Projekte zu laden, die zu anderen Teilen gehören. Dann ja, Sie können jedes Teil als separate Visual Studio Lösung haben.

Entscheidend ist, dass die VS-Lösung nur eine [.sln] -Datei ist, die beschreibt, welche Projekte nach dieser Lösung gruppiert sind. Erstellen Sie keine separaten Kopien von Projekten nur für diesen Zweck. Sie müssen alle Projekte nur einmal verwalten (jeweils eine Kopie) und dann separate Lösungen erstellen und Projekte einschließen, von denen Sie denken, dass sie mit dieser Lösung (diesem Teil des Codes) zusammenhängen.

z.B. Sie könnten entscheiden, dass "Employee Management" eine Lösung ist, die aus nur 3 (aus dem ganzen Haufen von 40) Projekten besteht. Dann gehen Sie voran und erstellen Sie eine Lösung, die diese drei Projekte enthält. Wahrscheinlich werden Sie am Ende separate kleinere Lösungen haben, die bequem in der Trennung von anderen arbeiten.

Sie können auch eine große Lösung mit allen darin enthaltenen Projekten in Betracht ziehen (wiederum jedes Projekt hat nur eine Instanz, kann aber Teil mehrerer Lösungen sein ). Diese Art von großer Lösung kann für wichtige Operationen wie Build / Release Vorbereitung nützlich sein.

Ich vermute, dass Sie versuchen, die Bedeutung einer Lösung zu übertreiben. In Wirklichkeit ist der gesamte Code, den Sie haben, eine riesige Einheit, weil sie sich gegenseitig referenzieren und wahrscheinlich nicht gebaut werden können, ohne andere neu zu kompilieren. Auch wenn Sie versuchen, die Lösungsstruktur zu finden, die Ihren Geschäftsanforderungen entspricht, scheint es dennoch eine andere Richtung eines Problems zu sein, das nicht mit Lösungen zu tun hat. Das kann etwas wie die Lösung eines Problems der Aufteilung in Baugruppen, dynamisches Laden und Erweiterbarkeit usw. sein.

Fazit: Split-Code in Lösungen abhängig von der Bequemlichkeit, die Sie bei der Arbeit mit dem Quellcode erreichen wollen, weil das einfach die Quelle in Unterteile unterteilt, nichts mehr.

BEARBEITEN / Hinzufügen:

Sie können auch entscheiden, die Lösung in unabhängige Lösungen aufzuteilen, aber das ist etwas anderes. Das würde bedeuten, dass die Lösungsprojekte nur auf die Ausgabedateien (dll, exe) anderer Projekte in anderen Lösungen verweisen können. Das könnte gemacht werden, wenn jede Lösung eine andere wie einen Code von Drittanbietern behandelt (keine direkten Projektreferenzen, sondern nur Referenzausgaben).

Ich denke, wenn Sie entscheiden, ob Sie mehrere Lösungen haben sollten, ist die Antwort wirklich Sie stellen sich eine (oder mehrere) der Baugruppen, die Ihren begrenzten Kontext in anderen Anwendungen verwendet werden, die einige der Genau dieselben Anwendungsfälle, die Ihr beschränkter Kontext verwaltet. Wenn das der Fall ist, macht eine separate Lösung Sinn. Aber wenn alle Ihre UI-Ebenen konzeptionell dieselbe Anwendung zur gleichen Zeit haben, würde ich sie in einer einzigen Lösung behalten, es sei denn, Sie haben so viele Projekte, dass Visual Studio unbrauchbar wird.

Ich wäre jedoch überrascht, wenn Sie wirklich eine andere Anwendung verwenden würden, die den gleichen beschränkten Kontext verwendet. Wenn Sie darüber nachdenken, möchten Sie vielleicht eine neuere Version der Logik, die NUR für Ihren Webdienst bereitgestellt wird, aber nicht für Ihre Windows Forms-Anwendung? Wahrscheinlich nicht, da die Logikänderungen seltsame Probleme einführen können, bei denen die Daten nicht das sind, was eine Anwendung erwartet.

Was Sie haben klingt wie eine Plattform, und alle Teile (UI-Ebenen) dieser Plattform sollte sollte genau die gleiche Logik ausgeführt werden.

Die Lösung Sicht ist nicht das Hauptproblem, denke ich. Ich würde wählen, meine Projekte in Ordnern zu organisieren. Eins für jeden begrenzten Kontext und das Web-UI in einem anderen (es könnte als eigener begrenzter Kontext gedacht werden, wenn man darüber nachdenkt).

Sie könnten einen freigegebenen Kernel haben, der von allen Ihren bc geteilt wird, den Sie vielleicht auch in einen anderen Ordner legen könnten.

Normalerweise sollte jeder bc unabhängig sein (mit Ausnahme der gemeinsam genutzten Assemblys), und Ihre UI sollte nur über ihre Schnittstellen (z. B. den WCF-Vertrag) die bc kennen

Die globale Lösung enthält möglicherweise alle Ordner und die darin enthaltenen Projekte (MyApplicationName.sln). Sie könnten jedoch eine dedizierte Lösung nur für einen Teil der Lösung verwenden, wie MyApplication_BCName nur mit dem Ordner bc, den gemeinsam genutzten Assemblys und der Benutzeroberfläche wenn es Ihren Bedürfnissen entspricht und Sie keine große Lösung haben wollen.

Beginne klein, mach Dinge, sobald du sie wirklich brauchst. Seien Sie besonders vorsichtig bei den Querverweisen, die Art und Weise, wie die Dinge in vs eingerichtet werden, ist wirklich bedeutungslos. Wenn Baugruppen lose gekoppelt sind, können Sie sie später jederzeit neu anordnen.

Ich bin kein erstklassiger Programmierer, ich habe zufällig gedacht, dass Dinge wie diese für die neuesten Projekte, an denen ich beteiligt war, gut zu funktionieren scheinen, sie könnten in ein paar Monaten (Stunden ... ??) komplett verändert sein. ;))