3

私の会社では、プレハブの Web アプリケーションを開発しています。多くの場合、私たちのアプリケーションはそのままで機能しますが、複雑なカスタマイズのリクエストを受け取ることもよくあります。これを構造化された方法で実行しようとすると、問題が発生します。一般的な機能は、カスタマイズの影響を受けるべきではありません。現在、Spring Web Flow を検討しており、必要なものの一部を処理できるようです。

たとえば、オンライン ショッピングがあり、ショッピング バスケットの注文をチェック アウトする瞬間に、独自のログ システムに書き込む必要があるクライアントからの要求があります。SWF を使用すると、汎用チェックアウト フローを ClientX チェックアウト フローで継承し、カスタム ログ書き込みを実行するために必要な状態で拡張することができます。このシナリオはうまく処理されているようです。これは、Open/Closed の原則に従って、Generic Checkout Flow をそのまま維持し、カスタム機能で拡張できることを意味します。私たちのチームは、一般的なチェックアウト フローに機能を追加し、拡張機能を変更せずにクライアントに配布することができます。ただし、クライアントがページのカスタマイズを要求する場合があります。たとえば、オンライン ショッピング アプリで、クライアントが複数の通貨機能をリクエストしたとします。この場合、ビューとフロー (コントローラー) を変更する必要があります。Generic View を変更せずに拡張できるテクノロジはありますか? これまでのところ、テンプレートベースのビュー (JSP、Struts、Velocity など) の大部分を備えたソリューションは 2 つだけのようです。

  • クライアントごとに特定のバージョンのビューを用意します。これは明らかに実装の爆発につながります
  • パラメータに応じてアプリケーションを構成可能にする (multipleCurrency の場合) コードの爆発につながる - 各ページで確認する必要がある多数の構成条件

この場合の最善の解決策は何でしょうか? 私が思い出すことができない他のカスタマイズのケースがおそらくいくつかあります。特定の基本ビューを拡張できるコンポーネント ベースのビュー テクノロジはあるのでしょうか。それは理にかなっています。構成可能な Web アプリケーションの問題に対する典型的な解決策は何ですか?

4

1 に答える 1

1

各カスタマイズ ポイントには、ある程度の条件が含まれています。

可能であれば、スタイルシートを使用していくつかの側面を制御する傾向があります。たとえば、通貨セレクターの表示はおそらくそのように行うことができます。

その通貨の例に対するもう 1 つの考え: 1 は多くの限定的なケースです。したがって、モデルは通貨のリストを提供します。ビューには、セレクターが多数ある場合はセレクターが表示され、1 つしかない場合は固定フィールドが表示されます。非常に明確に定義された動作 - 他のシナリオで再利用可能なテストが容易。

于 2009-08-05T15:04:29.070 に答える