2012-04-13 2 views
0

Es würde eine Anwendung geben, die 3 wichtige Dinge tun wird. A, B und C. Es wird eine C# winforms-Anwendung sein.Entwerfen Sie eine Suite von Produkten beim Erstellen/Pflegen nur einer

Unser CEO möchte, dass diese Anwendung in 6 verschiedene Produkte unterteilt wird.

  • Just A (Simple)
  • A + B (Fortgeschritten)
  • A + B + C (Ultimate)

und das alles für einen Benutzer oder mehrere Benutzer (Lizenzierung). So haben wir jetzt 6 Projekte!

Wenn wir annehmen, dass die drei Hauptteile tatsächlich getrennt sind und eigenständig arbeiten können, wie können wir ein Projekt aufrechterhalten und 6 verkaufen?

Im Moment gibt es drei Möglichkeiten, dies zu erreichen, die mir in den Sinn kommen:

A: eine grundlegende Rückgrat haben und als Modul jedes der A, B, C zu bauen. Auf diese Weise müssen wir uns nur mit dem Problem "Eine/viele Benutzer" auseinandersetzen.

B: Erstellen Sie ein solides Produkt, und verwenden Sie Präprozessordirektiven, um die Funktionalität zum Zeitpunkt der Kompilierung festzulegen. Das ist wirklich schwierig und macht Code hässlich. Auch könnte das Projekt brechen.

C: Erstellen Sie einen Versionsmechanismus, der so eingestellt wird, dass bestimmte Funktionen über die Anwendung zulässig sind. Dies ist am einfachsten, hat aber zwei Nachteile. Es ist leicht zu knacken und wir liefern die Ultimate-Version für einen einfachen Benutzer, was schlecht ist.

Ähnlich hierzu ist die Windows-Versionsverwaltung Ausgabe (Heim, Basic, Pro, Ultimate)

Wie sollen wir dieses Projekt entwerfen?

Antwort

1

1) Modularität - Die Entscheidung zwischen A- und B-Methode ist schwierig. Zunächst ist es wichtig, Modularität in Bezug darauf zu unterscheiden, wie sich die App für den Benutzer in UI und Modularität in der zugrunde liegenden Architektur der App darstellt. (Geschäftslogik, Datenschicht, usw.), während bestätigt wird, dass die zweite die erste widerspiegelt. AFAIK WinForms bietet keine sehr strikte Trennung von Darstellungsschicht und Business-Schicht, und Sie müssen zusätzliche Anstrengungen unternehmen, um die Schichten besser zu trennen, damit die Benutzeroberfläche flexibel bleibt, ohne dass viel Code neu geschrieben werden muss. Das heißt, wenn Sie die Business-Schicht so gestalten, dass sie "UI-Module" strikt widerspiegelt, werden Sie daran festhalten und dann ist es vielleicht einfacher, die Module entsprechend den Verkäufen zu schalten. Wenn Sie jedoch die Flexibilität in Zukunft bewahren möchten, trennen Sie die Schichten voneinander und deaktivieren Sie jede einzelne Funktionalität separat durch Präprozessordirektiven.

2) Endproduct vs. Produktion - Die Tatsache, dass Sie vielleicht verschiedene Endprodukte oder Builds haben, enthalten A oder A + B, 1 Benutzer oder viele Benutzer usw. bedeutet nicht, dass Sie den Code teilen müssen der Job auf diese Weise..Visual Studio ermöglicht es Ihnen sicher, Vorlagen für verschiedene "Release" -Builds zu erstellen, die dieses oder jenes Modul oder diese Funktionalität enthalten würden oder nicht.

Verwandte Themen