JSF Controller, Service und DAO

Ich versuche zu gewöhnen, wie JSF arbeitet mit Bezug auf den Zugriff auf Daten (kommen aus einer Quelle, hintergrund)

Ich bin ein einfaches Beispiel, das verwaltet eine Liste der Benutzer, ich habe so etwas wie

<h:dataTable value="#{userListController.userList}" var="u">
    <h:column>#{u.userId}</h:column>
    <h:column>#{u.userName}</h:column>
</h:dataTable>

Dann der "controller" hat so etwas wie

@Named(value = "userListController")
@SessionScoped
public class UserListController {
    @EJB
    private UserListService userListService;

    private List<User> userList;

    public List<User> getUserList() {
        userList = userListService.getUsers();
        return userList;
    }
}

Und der "service" (obwohl es scheint mehr wie eine DAO) hat

public class UserListService {

    @PersistenceContext
    private EntityManager em;

    public List<User> getUsers() {
        Query query = em.createQuery("SELECT u from User as u");
        return query.getResultList();
    }
}

Ist das der richtige Weg, Dinge zu tun? Ist meiner Terminologie ist richtig? Der "service" fühlt sich mehr wie ein DAO? Und der controller fühlt sich an wie es ist, etwas von der Arbeit des Dienstes.

InformationsquelleAutor der Frage PDStat | 2015-06-04

  1. 54

    Ist das der richtige Weg, Dinge zu tun?

    Abgesehen von der Durchführung von business-Logik der ineffizienten Weise, in einer managed-bean-getter-Methode, und verwenden eine zu Breite managed-bean-scope, es sieht okay aus. Wenn Sie den service-Aufruf aus der get-Methode, um eine @PostConstruct Methode, und verwenden Sie entweder @RequestScoped oder @ViewScoped statt @SessionScoped es besser Aussehen wird.

    Siehe auch:

    Ist meiner Terminologie ist richtig?

    Es ist okay. Solange du mit Ihr im Einklang, und der code ist lesbar in einer vernünftigen Weise. Nur Ihre Art der Benennung von Klassen und Variablen ist etwas umständlich (unlogische und/oder Vervielfältigung). Zum Beispiel, ich persönlich würde verwenden users statt userListund verwenden Sie var="user" statt var="u"und verwenden Sie id und name statt userId und userName. Auch ein "UserListService" wie es klingt, kann nur mit Listen der Benutzer und nicht-Benutzer im Allgemeinen. Ich würde eher von "UserService", so können Sie es auch verwenden, zum erstellen, aktualisieren und löschen von Benutzern.

    Siehe auch:

    Die "service" fühlt sich mehr wie ein DAO?

    Es ist nicht gerade ein DAO. Im Grunde, JPA ist der wirkliche DAO hier. Früher, als JPA nicht vorhanden, jeder homegrew DAO-Schnittstellen, so dass die service-Methoden halten können mit Ihnen, selbst wenn die zugrunde liegende Implementierung ("plain old" JDBC oder "gute, alte" Hibernate, etc) verpasst. Die eigentliche Aufgabe einer service-Methode ist transparent verwalten von Transaktionen. Dies ist nicht die Verantwortung des DAO.

    Siehe auch:

    Und der controller fühlt sich an wie es ist, etwas von der Arbeit des Dienstes.

    Kann ich mir vorstellen, dass es bedeutet, dass in diesem relativ einfachen Installation. Allerdings, der controller ist in der Tat ein Teil von dem frontend, nicht backend. Der Dienst ist Teil des backend, die entwickelt werden sollten, in solcher Weise, dass es wieder verwendbar in allen verschiedenen frontends, wie JSF, JAX-RS, "plain" JSP+Servlet, auch Swing, etc. Darüber hinaus werden die frontend-controller (auch als "backing bean" oder "Moderator"), die es Ihnen ermöglicht, sich in einen frontend-spezifische Art und Weise mit Erfolg und/oder Ausserordentliche Ergebnisse, wie in JSF Fall das anzeigen eines Flächen-Nachricht im Falle einer Ausnahme von ein service.

    Siehe auch:

    Alles in allem, der richtige Ansatz wäre wie folgt:

    <h:dataTable value="#{userBacking.users}" var="user">
    <h:column>#{user.id}</h:column>
    <h:column>#{user.name}</h:column>
</h:dataTable>
    @Named
@RequestScoped //Use @ViewScoped once you bring in ajax (e.g. CRUD)
public class UserBacking {

    private List<User> users;

    @EJB
    private UserService userService;

    @PostConstruct
    public void init() {
        users = userService.listAll();
    }

    public List<User> getUsers() {
        return users;
    }

}
    @Stateless
public class UserService {

    @PersistenceContext
    private EntityManager em;

    public List<User> listAll() {
        return em.createQuery("SELECT u FROM User u", User.class).getResultList();
    }

}

    Können Sie finden hier eine Reale Welt kickoff Projekt-hier unter Verwendung der kanonischen Java EE /JSF /CDI /EJB /JPA-Verfahren: Java EE-kickoff-app.

    Siehe auch:

    InformationsquelleAutor der Antwort BalusC

  2. 5

    Es ist ein dao, naja, eigentlich ein repository aber don t Sorge über die Differenz zu viel, da es den Zugriff auf die Datenbank mit dem Persistenz-Kontext.

    Erstellen Sie eine service-Klasse, die wraps, die Methode ist und wo die Transaktionen aufgerufen werden.

    Manchmal ist der service-Klassen fühlen sich überflüssig, aber wenn Sie haben eine service-Methode, die Anrufe viele dao-Methoden Ihr nutzen ist mehr gerechtfertigt.

    Ich normalerweise am Ende nur die Schaffung des Dienstes, auch wenn es fühlt sich unnötig, um sicherzustellen, die Muster bleiben die gleichen, und das dao ist nie direkt injiziert.

    Dies fügt eine zusätzliche Schicht der Abstraktion, um zukünftige Umgestaltung flexibler.

    InformationsquelleAutor der Antwort NimChimpsky

Schreibe einen Kommentar