4

私たちのアプリケーションでは、顧客ごとに GUI を少し変更する必要がある場合があります。

  • ある顧客には、他の顧客にはない入力フィールドがあります。
  • 別の顧客はすべてデフォルトのフィールドを持っていますが、オプションの入力フィールドの 1 つが必須です。
  • 3 番目の顧客にはデフォルトのフィールドがありますが、1 つのフィールドのキャプションが変更されています
  • 4 番目の顧客にはいくつかの新しい入力フィールドがあり、1 つの既存の複数行入力フィールドを単一行入力フィールドに変更する必要があります (新しいフィールド用のスペースを確保するため)。
  • ...

(注: これらの例はぎこちなく聞こえるかもしれませんが、これらはお客様が求めたものです)

これらのケースをどのように処理しますか？

  • 一般に
  • Java/Swing で

現在、最も一般的な方法でフォームを設計しています。実行時に、フィールドの非表示、サイズ変更、位置変更などの調整を行います。入力の検証では、アクティブな顧客に応じてコンテンツを検証します。

4

6 に答える 6

5

これにはいくつかの方法があります。ただし、状況に大きく左右されます。

  1. 同じ画面に異なる顧客ロジックを追加する代わりに、顧客ごとに異なる画面を用意し、デフォルトの画面を全員が使用するようにします。

  2. カスタム ビルドまたは顧客のブランチ。これはかなり複雑になる可能性がありますが。

  3. これまでとまったく同じように行い、顧客固有のロジックを画面に埋め込みます。

  4. ある種のルール エンジンを使用して、インターフェイスを駆動します。

于 2009-01-15T15:20:52.940 に答える
3

この問題には、フォームレイアウト、データベースストレージ、および構成可能なビジネスロジックの3つの側面があります。

構成主導のフォームレイアウト

フォームレイアウトへの柔軟なアプローチは、レイアウトを記述子ファイルに移動することで実現できます。これをサポートする3つのGUIツールキットは、QT、WPF、およびXULです。ただし、AFAIKSwingはこの機能を直接サポートしていません。QT Jambiでは、Swingの代わりにJavaでQTを使用でき、QT4.5はLGPLライセンスで利用できるようになります。これは純粋なJavaソリューションではありませんが、これとそれに伴うUIコードの書き直しが許容できる場合は可能性があります。

構成主導型のフォームレイアウトの利点は、顧客ごとに個別のビルドを維持することなくカスタマイズできることです。したがって、既存のコードベースがある場合でも、そのようなものを採用するビジネスケースがあるかどうかを調べることができます。ツールキットと複数の顧客固有のビルドの維持。ただし、コンパイルされた言語の場合でも、生成されたフォームコードに対して何らかのプラグインフレームワークを設定する必要がある場合があります。

構成可能なデータベースストレージ

これはもっと複雑です。これは、長所と短所の3つの方法で行うことができます。

  1. 最初のアプローチは、「User1」、「User2」などの一連の「user」フィールドをテーブルに配置することです。フォームの構成済みフィールドはこれらのフィールドにマップできます。一般的なユーザーフィールドマッピング機能は、実装が難しい。これは、データベースクエリの観点からは最も効率的ですが、可能なフィールドの数が限られているという制限があります。フィールド「User1」から「User20」がある場合、サポートできるのは20個のユーザー定義属性のみです。また、それらは素晴らしく、幅の広い汎用varcharである必要があるため、データベースから型の安全性を得ることができません。

  2. 2番目のアプローチは、属性テーブルをエンティティにぶら下げることです。これは型の安全性を与えるものではありませんが、必要な数の属性を持つことができます。このための汎用ハンドラーを構築することも非常に実行可能ですが、属性テーブルに対して複数の結合を行うと、クエリのパフォーマンスが影響を受けます。

  3. ユーザー定義フィールドをXMLBLOBに永続化します。これは、データベースを介したデータへのアクセスを困難にするため、推奨することはほとんどありません。しかし、私はそれが行われるのを見てきました。

構成可能なビジネスロジック

これははるかに厄介な問題です。カスタムコードを追加したりビルドを変更したりせずに、構成可能なビジネスルールを実行するためのいくつかのオプションがあります。ルールエンジン、スクリプト言語、または必須フィールドなどの標準のオン/オフ機能のセットです。

  1. ルールエンジン：これらを使用するには、アプリケーションを最初から設計する必要があり、独自の制限と失敗があります。この分野の現職であるILOGもかなり高価です。Javaの場合、JESSがオプションになる可能性があります。

  2. 埋め込みスクリプト言語：Jython、Groovy、またはその他のJVMに適したインタープリター言語を追加することで、新しいビルドを発行することなく、システムのプラグインを作成できます。一部のテストワークロードは引き続き発生しますが、これは全体としてメンテナンスのメリットになる可能性があります。

  3. 機能のオン/オフ構成。これは最も柔軟性の低いオプションですが、比較的単純であり、外部の依存関係とライセンスコストの点で比較的わずかしか追加されません。特注のアプリケーションとして誕生したものに構成を後付けしようとしている場合も、これが唯一の選択肢となる可能性があります。

上記のどれでもない

答えが「上記のどれでもない」の場合、おそらくカスタムビルドで立ち往生しています。その場合は、フォームのプラグインアーキテクチャを作成して、少なくとも顧客固有のアイテムを別のモジュールに分離できるようにします。

于 2009-01-15T15:57:50.073 に答える
3

私は4つのアプローチを考えることができます：

  1. しないでください。うん、もう手遅れなのはわかってるけど、もし我慢できるなら、いつも定番商品を売ってね。

それが不可能なら...

  1. 各顧客がボックスにチェックを入れて独自の要件を定義できる機能マトリックスを作成します (フィールド無効、提示必須、提示オプションなど)。UI で情報を表示する方法が制限されます。よりシンプルなデザインに傾向がありますが、スケーラブルで柔軟です。
  2. 顧客ごとにカスタム ページを用意し、各ページがビジネス ロジックと検証に関してそれ自体をサポートします。おそらく、各顧客に提供される 3 つまたは 4 つのバリエーションでうまくいく可能性があります。
  3. 分岐。これを行う場合、それは高価な PITA であるため、顧客が支払うことを確認してください。
于 2009-01-15T15:34:55.453 に答える
1

これがどのタイプのアプリケーションかはわかりませんが、競合する機能要求を受け取った場合、通常、各クライアントのバージョンを分岐し、各分岐に関連するコードのみを含めます。

何らかのコード管理/バージョン管理システムを使用していますか? SVN は私たちが使用しているもので、メイン コードに変更を加えるたびに各ブランチを更新できるため、コードが古くなることはありません。

于 2009-01-15T15:18:41.290 に答える
1

MS Access 内の FORMS 作成画面と同様のことを行い、顧客が自分で入力を追加/削除/変更および設定できるようにします。また、必須のフィールドとそうでないフィールドを設定することもできます。フロントエンドでの作業が増えますが、バックエンドでの作業は減ります。

于 2009-01-15T15:26:11.697 に答える
1

ある種のプラグイン システムを使用することをお勧めします。顧客ごとに、アプリケーションの UI を変更するプラグインを作成し、起動時にロードするだけです。私は Java プログラマーではないので、残念ながら特定のコード スニペットを投稿することはできません。

于 2009-01-15T15:33:07.237 に答える