3

Web サイトのリボン/実績システムをコーディングしていますが、システム内の各リボンにいくつかのロジックを記述する必要があります。たとえば、最初の 2,000 人が Web サイトに登録した場合、またはフォーラムに 1,000 件の投稿があった場合、リボンを獲得できます。このアイデアは、実際には、stackoverflow のバッジと非常によく似ています。

したがって、すべてのリボンは明らかにデータベースにありますが、ユーザーがいつリボンを獲得したかを判断するためのロジックも少し必要です。

私がコーディングした方法でRibbonは、シンプルなインターフェースです：

public interface Ribbon {
    public void setId(int id);
    public int getId();
    public String getTitle();
    public void setTitle(String title);
    public boolean isEarned(User user);
}

RibbonJpaメソッドRibbonの定義を回避して、インターフェースを実装する抽象クラスです。isEarned()

@Entity
@Table(name = "ribbon")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "ribbon_type")
public abstract class RibbonJpa implements Ribbon {
    @Id
    @Column(name = "id", nullable = false)
    int id;

    @Column(name = "title", nullable = false)
    private String title;

    @Override
    public int getId() {
        return id;
    }

    @Override
    public void setId(int id) {
        this.id= id;
    }

    @Override
    public String getTitle() {
        return title;
    }

    @Override
    public void setTitle(String title) {
        this.title = title;
    }
}

継承戦略を次のように定義していることがわかりますSINGLE_TABLE(50 個のリボンのようにコーディングする必要があり、それらのいずれにも追加の列は必要ないため)。

これで、特定のリボンが次のように実装されます。

@Entity
public class FirstUsersRibbon extends RibbonJpa implements Ribbon {
    public FirstUsersRibbon() {
        super.setId(1);
        super.setTitle("First 2,000 users registered to the website");
    }

    @Override
    public boolean isEarned(User user) {
        // My logic to check whether the specified user has won the award
    }
}

このコードは正常に動作し、期待どおりにテーブルがデータベースに作成されます (ローカル環境で DDL 生成を使用しています)。

問題は、ドメイン オブジェクトでビジネス ロジックをコーディングするのは間違っていると感じることです。それは良い習慣ですか？より良い解決策を提案できますか? また、エンティティ ( ) 内の DAO を Autowire することができずFirstUsersRibbon、ビジネス ロジックでそれらが必要です (この場合、ユーザーが Web サイトに登録された最初の 2,000 ユーザーに含まれているかどうかを確認するために DAO が必要です)。

どんな助けでも大歓迎です。

ありがとうございました！

4

2 に答える 2

11

問題は、ドメインオブジェクトにビジネスロジックをコーディングするのは間違っていると感じることです。

多くの人は、その逆が真実であると言うでしょう。それは、他の場所にビジネスロジックを持つことはアンチパターン（貧血のドメインモデル）であるということです。詳細については、ドメイン駆動設計を参照してください。

次に、従来の3層アーキテクチャの中間層が何のためにあるのか疑問に思うかもしれません。アプリケーションにサービスレイヤーを提供します。関連する質問「EJBの用途は何ですか？」を参照してください。

于 2012-05-20T19:41:13.013 に答える
0

また、エンティティ内のDAOを自動配線できません

SpringとHibernateを使用している場合は、 http： //jblewitt.com/blog/ ？p = 129を参照してください。これにより、さまざまなソリューションでの同様の問題の適切な説明が得られます。

説明した方法でリッチドメインモデルを探している場合は、Springを介してドメインオブジェクトをインスタンス化することをお勧めします。これにより、ドメインオブジェクトにDAOを挿入できるようになります。

于 2012-05-20T20:23:26.983 に答える