1

一連のアイテムが定義されているとします。これらのアイテムは、異なるセットにグループ化する必要があります。例：アイテムは次のようになります

public Item {
    public int id;
    public String name;
}

セットには、このセットに属するアイテム、セットの名前などの独自の設定があります。すべてのものは、xml 構造などに保存されます。

私の最初のアイデアは、次の要素を書くことです：

  • セットのデータを取得して MySet pojo に変換する xml パーサー

  • すべてのアイテムを取得し、アイテム pojos のリストに変換する xml パーサー

  • ステートレス サービスのようなクラスは、ItemsSetCreator が、MySet に基づくセットの定義と次のようなアイテムのリストを含む最終的な ItemsSet オブジェクトを計算すると言います

    class ItemsSetCreator {

     public ItemsSet createItemsSet(List<Item> items, MySet set) {
         // ...
     }
}

しかし、別のアプローチは、モデルを少し充実させ、sht を次のように記述することです。

  • MySet クラスは、すべてのアイテムを取得し、xml-data に基づいてそれらに内部ロジックを適用し、結果として最終的な ItemsSet を提供することができます

  • 等

どっちがいいのかわからない。たとえば、Spring がよりサービス中心のアプローチを推進していることは知っていますが、最近貧血モデルの回避について多くの話題があります。

4

1 に答える 1

1

それはすべてユースケースと粒度に依存するため、質問に明確に答えることは困難です. モデルを充実させることは良いことですが、滑りやすい坂道を下りたくはありません。

高度に結合されたスパゲッティ コードの「豊富な」モデルと退屈な貧血モデルのどちらかを選択する必要がある場合は、貧血モデルを選択する必要があります。しかし、ここでreductio ad absurdumを使用しても何も解決しないため、元のポイントに戻ります。それはユース ケースによって異なります。モデルに動作が必要な場合があります。時々あなたはしません。ほとんどの場合、あなたは真ん中のどこかにいます。

ビヘイビアー モデルに本当に必要な量を見つけるのは、開発者およびアーキテクトとしてのあなたの仕事です。

作業しているものが分散している場合は、ステートフル モデルに反対することをお勧めします。ノード間で状態を共有する (デッドロックや競合状態を回避する) ことは自明ではありません。

于 2012-02-20T19:42:31.727 に答える