9

私のキャリアの中で、私はいくつかの異なるデザイン、レイヤーの操作方法を見DAOましたService。Controller似ているが違いが少ない2つについてお聞きしたいのですが。最初の設計では、レイヤー間に目に見えるバリアが作成されます。コントローラーは常にサービスを使用し、サービスのみを使用します。サービスは他のサービスまたはを使用できますDAO。コントローラはDAO直接使用することはできません。この設計は明確ですが、私にとって大きな欠点があります。常に、のメソッドごとにインサービスのメソッドを作成する必要がありますDAO。しかし、多くの場合、メソッドはsメソッドとその他のものServiceのみを呼び出します。DAO

例：UserDao

class UserDao {
    public List<User> findByName(String name) { ... }
    public List<User> findByLastName(String name) { ... }
    public List<User> findOlderThan(int age) { ... }

    ......
}

上記のすべてのメソッドは、によって使用されControllersます。私たちの場合、私たちは何をすべきですか？で同様のメソッドを作成しますUserService：

class UserService {
    public List<User> findByName(String name) { return userDao.findByName(name); }
    public List<User> findByLastName(String name) { return userDao.findByLastName(name); }
    public List<User> findOlderThan(int age) { return userDao.findOlderThan(age); }

    ......
}

私にとって、これは読み取り専用メソッドの追加の不要なレイヤーです。

2番目の設計では、コントローラーでDAOを直接使用できるため、これに問題はありません。この設計にはルールがあります。「データストア」からデータを取得する場合DAOは任意のレイヤーで使用でき、「データストア」に変更を加える場合はサービスメソッドを使用する必要があります。

皆さん、これらのデザインについてどう思いますか？どちらが良いですか？プロジェクトでどちらを使用する必要があり、どちらを忘れる必要がありますか？この分野でのあなたの経験を教えていただけますか？

4

1 に答える 1

3

MVCおよびMVCに着想を得たデザインパターンのサービスは、モデルレイヤーの「最上位」です。これは、プレゼンテーション層がドメインビジネスロジックと相互作用する方法です（また、「読み取り」部分は、実際にはビューインスタンスによって実行される必要があります）。

このような構造では、サービスがバリアとして機能し、プレゼンテーション層を分離して、後でモデルの内部構造を変更する際の自由度を高めます。

覚えておく必要があるもう1つのことは、サービスが相互作用するDAOだけでなく、より多くの構造があるということです。まず、 1つの特定のエンティティに関連するさまざまなビジネスルールをカプセル化するドメインオブジェクト（ビジネスオブジェクト、モデルオブジェクト）があります。次に、DAOの代わりにストレージロジックを抽象化するデータマッパーを使用することもできます。または、マッパーとドメインオブジェクト間で情報を変換するDAO。大規模なアプリケーションでは、作業単位もあります。小規模では、いくつかのアクティブなレコードインスタンスで問題ありません。

モデルレイヤーには、ドメイン、ストレージ、アプリケーションロジックという、モデルの個別の側面を実装する3つの主要な構造グループが含まれていると言えます。

アプリケーションロジックは、ストレージ構造ドメインオブジェクト間の相互作用です。それがサービスの責任です。

DAOを公開すると、モデルレイヤーがプレゼンテーションでリークし始めます。コントローラは、どの構造が使用され、いつそれらが永続化されるかについては知らないはずです。

于 2013-02-11T23:00:23.840 に答える