構成可能なアプリケーションのためのアーキテクチャ/パターン

Question

私はすでにasp.netフォーラムでこの質問をしましたが、満足できる答えが見つかりませんでした。 あなたはそれを訪問して詳細を得ることができます。 http://forums.asp.net/t/1420283.aspx

私たちには、クライアントごとに設定できる製品があります。

設定オプションは、UIとビジネスロジックです。

UIでは、任意のページのすべてのコントロールを任意の方法で並べ替えることができます。表示したくないコントロールは非表示にします（別のクライアントの要求に応じているため）。

ビジネスロジックでは、多くの "Switch/Select Case"が各クライアントの設定に従ってロジックを実装するように分岐します。 （クライアントに応じて実行時に外部アセンブリ/ dll（プロジェクトが構築された）プラグインを選択できれば、共通のコードベースは各クライアントが外部のコードを呼び出して、必要に応じて処理することを意味します。 .....または多分別のクライアントのロジックを自分のクラスで分離する）

今のところUIは完全に実行時に構築されています.....一度設定してから私の意見では（IMO）は必要ありませんUIはクライアントのために静的なままです（非常に少ない拡張機能を除いて）。

しかし、私たちは、より簡単な乗り換えのための単一のコードベースを維持したいと考えています。 （少なくとも、ビジネスロジック、私は共通のテンプレートから生成された、各クライアントごとに異なるUIを持つことについて疑問に思います）。

私はこれが異なる製品のために百倍であったに違いないと確信しています...しかし、私は決して1つを越えていません。私はインターネット上で何も見つけることができません。

Answer 1

は、この種のものに関するガイダンスのためのDjangoフレームワークを見てください。

1. 各クライアントには、ライブラリとコンポーネントの共通セットから構築された別の「アプリケーション」があります。クライアント固有のアプリケーションは、コアアプリケーションの拡張機能です。

2. 表示機能実際の作業を行います。

   私たちは、ビュー機能を2つの層に分けています。最上位層は顧客固有の層であり、汎用コンポーネントのライブラリが含まれています。

   各クライアントのロジックは固有のロジックなので、「スイッチ/セレクトケース」ブランチはありません。クライアントバージョンを書くために必要な労力を最小限に抑えるために、我々はジェネリックコンポーネントライブラリと同じくらい多くの汎用ロジックを組み込んでいます。私たちは常に、複数のクライアントによって使用されるものを汎用ライブラリに移動し、クライアントコードを書き直して単純化しています。

3. テンプレートはHTMLページを生成します。

   テンプレートはテンプレートの検索パスにあります。

   各顧客は、カスタマイズされたテンプレートディレクトリがデフォルトテンプレートの前に検索されるように、異なる検索パスを持つことができます。

大量のアプリケーションに大量のif文を組み込んでいるわけではありません。一般的な一般的なベースラインアプリケーションを拡張するいくつかの小さなアプリケーションがあります。

Answer 2

あなたのビジネスロジックについては、ユーザーの設定に基づいてかなり複雑なことをしようとしているように思えます。商用ルールエンジンについて考えることをお勧めします。私は過去に使用さ見てきた1年代の一つは次のとおりです。

InRule