1

私は、Struts2、Hibernate、およびSpringを使用してsessionFactoryのライフサイクルを管理する中規模のアプリケーションに取り組んでいます。私の質問は、アプリケーション全体にすべてのサービスを提供する1つの大きなサービスクラスを作成する必要があるということです。またはモデルごとに1つのサービスクラスを作成する必要がありますか？

私はこの1つの大きなサービスクラスを持っているとしましょう

@Transactional
public class Services {
    // So Spring can inject the session factory
    SessionFactory sessionFactory;
    public void setSessionFactory(SessionFactory value) {
        sessionFactory = value;
    }

    // Shortcut for sessionFactory.getCurrentSession()
    public Session sess() {
        return sessionFactory.getCurrentSession();
    }

    public Event getEventById(long id) {
        return (Event) sess().load(Event.class, id);
    }

    public Person getPersonById(long id) {
        return (Person) sess().load(Person.class, id);
    }

    public void deleteEventById(long id) {
        sess().delete(getEventById(id));
    }

    public void deletePersonById(long id) {
        sess().delete(getPersonById(id));
    }

    public void createEvent(String name) {
        Event theEvent = new Event();
        theEvent.setName(name);
        sess().save(theEvent);
    }

    public void createPerson(String name) {
        Person p = new Person();
        p.setName(name);
        sess().save(p);
    }

    @SuppressWarnings("unchecked")
    public List<Event> getEvents() {
        return sess().createQuery("from Event").list();
    }

    @SuppressWarnings("unchecked")
    public List<Person> getPeople() {
        return sess().createQuery("from Person").list();
    }

    public void removePersonFromEvent(int personId, int eventId) {
        getEventById(eventId).getPeople().remove(getPersonById(personId));
    }

    public void addPersonToEvent(int personId, int eventId) {
        getEventById(eventId).getPeople().add(getPersonById(personId));
    }

      .....Some more services methods here
}

これに対する最善のアプローチは何でしょうか？アプリケーション全体に1つの大きなサービスクラス？またはモデルごとに異なるサービスクラス？

4

2 に答える 2

3

エンタープライズパターンに関するMartinFowlerの本には、サービスレイヤーの構築に関するいくつかの優れたガイドラインがあります。本の抜粋であなたはこれを見つけることができます：

十分に小さいアプリケーションの場合、アプリケーション自体にちなんで名付けられた抽象化を1つだけ持つだけで十分な場合があります。私の経験では、大規模なアプリケーションはいくつかの「サブシステム」に分割されており、各サブシステムには、アーキテクチャ層のスタックを通る完全な垂直スライスが含まれています。

したがって、サービスレイヤーパターンには石で書かれた法則はありません。あなたは小さなアプリケーションの場合ではないように感じます（Servicesクラスのメソッドが多すぎる）ので、すべてがアプリケーションのサブシステムを識別することになります。この本はまた、市長の抽象化（多分EventServiceまたはPeopleService）またはアプリケーションの動作（のようなEventManagementService）に関連するサービスレイヤーを推奨しています。最終的には、プロジェクトに最適なコード編成を決定するのはあなた次第です。

于 2012-12-03T03:56:39.040 に答える
0

完全なアプリケーションのために1つの大きなサービスを作成することは、そのような意味がなく、アプリケーションが成長するにつれて、readability同様に問題が発生し始めます。maintenance

モジュラーアプローチに従うのが常に良いです。@Asagによって提案されたように：

モジュールごとに異なるサービスを作成し、そこでサービスに関連するメソッドを定義します。これは、機能を分離するのに役立ち、同じアプリケーションで作業する将来の人にも役立ちます。

于 2012-12-03T02:45:49.253 に答える