Tweet
Hallo,
es gibt diverse Lehrmeinungen zur optimalen Strukturierung von Projekten, z.B. aus einem MS Artikel von 2002, wo empfohlen wird, möglichst nur mit einer einzigen Solution zu arbeiten, in die dann alle Teilprojekte eingehängt werden sollen. Dies, sowie die bevorzugte Verwendung von Projektreferenzen an Stelle einfacher Dateireferenzen würde zu bester Produktivität ohne Inkonsistenzschmerzen führen.
Ein anderer Autor empfiehlt, prinzipiell jede Assembly (= Komponente) in einer eigenen Solution zu halten, die dann gleich auch entspr. Testprojekte für Unittests enthält. Die vielen Solutions werden dann möglichst mit externen Build-Tools auf einem Buildserver aktuell gehalten.
Diese Variante erfordert, dass möglichst streng nach Contract First Design gearbeitet wird, wo ein jeder alle externen Assemblies aus dem gleichen Projekt nur über Interfaces referenziert und möglichst auch nicht über direkte Filereferenzen instanisiert. Stattdessen verwende man eine zur Laufzeit parametrisierbare Objectfactory, wie z.B. Microkernel oder einen der diversen Dependency Injection Container.
Ich habe mal ein Projekt nach der 2. Variante (Multi-Solution) aufgesetzt, dann aber doch festgestellt, dass stabile Interfaces und die Verwendung von Mocks als temporärer Ersatz für noch nicht fertiggestellte Assemblies schön wären, aber leider nicht funktionieren "as advertised". Im Projektalltag gibt es öfters Störfeuer und dass ständige Hin- und Herspringen zwischen den Solutions, sowie der solutionübergreifende (komplizierte) Buildprozess scheinen mir aufwendiger als nötig zu sein.
Wie verhält sich dagegen eine Single-Solution Lösung, wenn mehrere Leute daran arbeiten wollen? Ist sowas machbar oder empfehlenswert?
Wie strukturiert ihr eure Projekte? Immer gleich oder mal so, mal anders?
Ich könnte mir vorstellen, dass eine feste Struktur in einer Firma schon aus Wartbarkeitsgründen zu bevorzugen wäre.
Gruß
Ingo
es gibt diverse Lehrmeinungen zur optimalen Strukturierung von Projekten, z.B. aus einem MS Artikel von 2002, wo empfohlen wird, möglichst nur mit einer einzigen Solution zu arbeiten, in die dann alle Teilprojekte eingehängt werden sollen. Dies, sowie die bevorzugte Verwendung von Projektreferenzen an Stelle einfacher Dateireferenzen würde zu bester Produktivität ohne Inkonsistenzschmerzen führen.
Ein anderer Autor empfiehlt, prinzipiell jede Assembly (= Komponente) in einer eigenen Solution zu halten, die dann gleich auch entspr. Testprojekte für Unittests enthält. Die vielen Solutions werden dann möglichst mit externen Build-Tools auf einem Buildserver aktuell gehalten.
Diese Variante erfordert, dass möglichst streng nach Contract First Design gearbeitet wird, wo ein jeder alle externen Assemblies aus dem gleichen Projekt nur über Interfaces referenziert und möglichst auch nicht über direkte Filereferenzen instanisiert. Stattdessen verwende man eine zur Laufzeit parametrisierbare Objectfactory, wie z.B. Microkernel oder einen der diversen Dependency Injection Container.
Ich habe mal ein Projekt nach der 2. Variante (Multi-Solution) aufgesetzt, dann aber doch festgestellt, dass stabile Interfaces und die Verwendung von Mocks als temporärer Ersatz für noch nicht fertiggestellte Assemblies schön wären, aber leider nicht funktionieren "as advertised". Im Projektalltag gibt es öfters Störfeuer und dass ständige Hin- und Herspringen zwischen den Solutions, sowie der solutionübergreifende (komplizierte) Buildprozess scheinen mir aufwendiger als nötig zu sein.
Wie verhält sich dagegen eine Single-Solution Lösung, wenn mehrere Leute daran arbeiten wollen? Ist sowas machbar oder empfehlenswert?
Wie strukturiert ihr eure Projekte? Immer gleich oder mal so, mal anders?
Ich könnte mir vorstellen, dass eine feste Struktur in einer Firma schon aus Wartbarkeitsgründen zu bevorzugen wäre.
Gruß
Ingo
Comment