0

3 つの主要な処理を実行するアプリケーションがあります。A、BおよびC。これは、C# の winforms アプリケーションになります。

当社の CEO は、このアプリケーションを 6 つの異なる製品に分割することを望んでいます。

  • ジャスト A (シンプル)
  • A + B (上級)
  • A + B + C (アルティメット)

これらすべては、1 人のユーザーまたは複数のユーザー (ライセンス) に適用されます。これで6つのプロジェクトができました！

3 つの主要部分が実際に分離されており、単独で機能すると仮定すると、1 つのプロジェクトを維持しながら6つのプロジェクトを販売できるでしょうか?

現時点では、これを達成する方法が 3 つあります。

A:基本的なバックボーンを持ち、A、B、C のそれぞれをモジュールとして構築します。このようにして、「1 人/多数のユーザー」の問題に対処するだけで済みます。

B: 1 つの堅固な製品を作成し、プリプロセッサ ディレクティブを使用してコンパイル時に機能を設定します。これは非常に難しく、コードが見苦しくなります。また、プロジェクトが壊れる可能性があります。

C:アプリケーションで特定の機能を許可するように設定されるバージョン管理メカニズムを作成します。これは最も簡単に実行できますが、2 つの欠点があります。クラックは簡単で、単純なユーザーには Ultimate バージョンを提供しますが、これは悪いことです。

これと同様に、Windows のバージョン管理の問題 (Home、Basic、Pro、Ultimate) があります。

このプロジェクトをどのように設計する必要がありますか?

4

1 に答える 1

1

1)モジュール性・A方式とB方式の判断が難しい。まず、アプリが UI でユーザーにどのように表示されるかという点でモジュール性を区別し、アプリの基盤となるアーキテクチャでモジュール性を区別することが重要です。（ビジネスロジック、データレイヤーなど）2番目が1番目を反映していることを認めながら。私の知る限り、WinForms はプレゼンテーション レイヤーとビジネス レイヤーを厳密に分離していません。多くのコードを書き直さなくても UI に柔軟性を持たせるには、レイヤーをより適切に分離するための追加の努力が必要です。これは、「UI モジュール」を厳密に反映するようにビジネス レイヤーを設計すると、それに行き詰まり、売上に応じてモジュールを切り替える方が簡単になることを意味します。ただし、将来の柔軟性を維持したい場合は、

2)最終製品と本番- A または A+B、1 人のユーザーまたは多数のユーザーなどを含むさまざまな最終製品またはビルドが存在する可能性があるという事実は、コードとジョブをそのように分割する必要があるという意味ではありません。 Visual Studio では、さまざまな「リリース」ビルド用のテンプレートを確実に作成できます。これには、特定のモジュールまたは機能が含まれている場合と含まれていない場合があります。

于 2012-04-13T14:35:26.493 に答える