2

これは簡単なことだと思いますが、ベストプラクティスが何であるかについて明確な答えは見つかりませんでした。

アプリケーションでは、注文の現在のステータス (オープン、キャンセル、発送済み、クローズなど) を保持します。この変数はコードを変更しないと変更できませんが、アプリケーションは次の基準を満たす必要があります。

  1. ステータス名は、さまざまな言語で簡単に表示する必要があります。
  2. アプリケーションは、フリーテキストのステータス名で検索できます (「オープン」のグーグル検索など)。
  3. status_id は、列挙型を介して開発者が利用できる必要があります
  4. 新しいステータスを追加する際の頭痛の種なし

これまでにこれに取り組んできた可能な方法は次のとおりです。

  1. PK(id, language_id) を含む DB テーブルのステータスと、アプリケーションでこのステータスを表す別の列挙型を持つ。 長所: 1.,2.,3. すぐに使える、短所: 4. すべてのクライアント インストールで更新スクリプトを実行する必要がある
  2. 列挙するだけです： 長所： 3.、4。短所: 1.,2. 完全な悪夢です
  3. アプリケーションの開始ごとにデータベーステーブルにデータを入力する列挙型を持つ： 長所： 1.、2.、3.、4. 作業短所:アプリケーションの起動時に多少のオーバーヘッドが発生します。多くのコード テーブルを処理する場合、SQL 選択が大きくなり、扱いにくくなる可能性があります。

この問題に取り組む最も一般的な方法は何ですか?

4

4 に答える 4

0

1. ステータス名はさまざまな言語で簡単に表示できる必要があります。2. アプリケーションはフリーテキストのステータス名で検索できます (「オープン」のグーグル検索など)。

これらはインターフェイス レイヤーの問題です。ドメイン モデルに混在させない方がよいでしょう。

ステータス列挙型と i18n コードの間のマッピングをセットアップします。マッピングは、ファイルに保存する (メモリにキャッシュする) か、ハードコードすることができます。

例: dto または view adatper を使用して UI をレンダリングする場合。

public class OrderDetailViewAdapter {
     private Order order;

     public String getStatus() {
         return i18nMapper.to(order.getStatus());//use hardcoded switch case or file impl
     }
}

または、dtos を設定する前にこれを行うこともできます。

ゴール 2 にも同様のソリューションを使用できます。ユーザーがテキストを入力すると、マッピングから対応する列挙型を見つけ、検索に列挙型を使用します。

とにかく、db テーブルを使用しないほど良いです。

于 2013-09-19T01:10:41.743 に答える
0

私は方法 3 を使用しますが、これは最善の方法です。リソース ファイルを使用して翻訳を保存し、列挙値をリソース ファイル内のキーにマップできます。データベースには、ステータスの列挙型の ID を含めることができます。

于 2013-09-18T16:59:53.930 に答える
0

あなたはそれを自分でかなりうまく要約しているように聞こえます.3に向けて長所/短所を比較しています. ただし、＃3を実装するときのコメントは1つだけです：

キャッシュ メカニズム (単純な HashMap でも!) を使用し、さらにキャッシュを更新するオプションを追加すると、値を変更する必要がある場合に作業が容易になります (毎回再起動する必要はありません!)。

于 2013-09-18T17:09:30.757 に答える