0

私はすでにasp.netフォーラムでこの質問をしましたが、満足のいく答えが見つかりませんでした. にアクセスして詳細を確認できます。 http://forums.asp.net/t/1420283.aspx

クライアントごとに構成できる製品があります。

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

UI では、特定のページ内のすべてのコントロールを好きなように再配置することを選択できます。表示したくないコントロールは非表示にします (それらは別のクライアントの要求によるため)。

ビジネスロジックでは、各クライアントの設定に従ってロジックを実装する多くの「Switch/Select Case」ブランチがあります。（クライアントに応じて、実行時に外部アセンブリ/ dll（ビルドされたプロジェクト）をプラグインすることを選択できるかどうか疑問に思っています。これは、共通のコードベースが各クライアントの外部コードを呼び出して、必要に応じて処理することを意味します.... ...または、異なるクライアントのロジックを独自のクラスに分離するだけかもしれません)

現在、UI は実行時に完全に構​​築されています。私の意見では (IMO) は必要ありません。一度構成すると、UI はクライアントに対して静的なままになるためです (非常に少数の強化を除いて)。

しかし、メンテナンスを容易にするために単一のコード ベースを維持したいと考えています。(少なくともビジネス ロジックについては、共通のテンプレートから生成された、クライアントごとに異なる UI を使用することについて疑問に思っています)。

これはさまざまな製品で何百回も行われたに違いないと確信しています...しかし、私は一度も遭遇したことがなく、インターネット上で何も見つかりません.

4

2 に答える 2

2

ビジネスロジックに関しては、ユーザー設定に基づいてかなり複雑なことをしようとしているようです。役立つ商用ルール エンジンについて考えてみてください。過去に使用されたものの1つは次のとおりです。

インルール

于 2009-08-06T15:36:58.683 に答える
1

この種のガイダンスについては、Django フレームワークを参照してください。

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

  2. ビュー関数は実際の作業を行います。

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

    各クライアントのロジックは独自のロジックであるため、「Switch/Select Case」ブランチはありません。クライアント バージョンの作成に必要な労力を最小限に抑えるために、汎用コンポーネント ライブラリからできるだけ多くの汎用ロジックを組み込みます。私たちは常に、複数のクライアントで使用されるものを汎用ライブラリに移動し、クライアント コードを書き直して簡素化しています。

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

    テンプレートは、テンプレート検索パスで見つかります。

    カスタマイズされたテンプレート ディレクトリが既定のテンプレートの前に検索されるように、顧客ごとに異なる検索パスを設定できます。

それを調整するための if ステートメントがたくさんある大規模なアプリケーションを持っていないもの。一般的で一般的なベースライン アプリケーションを拡張する小さなアプリケーションが多数あります。

于 2009-08-06T15:55:55.417 に答える