Verwenden von Diensten und DAOs im Frühjahr mvc-Controller

Question

Ich baue eine Web-Anwendung, die hauptsächlich aus CRUD-Operationen von Daten aus Back-End/Datenbank besteht. Es gibt Fälle, in denen ich Geschäftslogik schreiben muss (ich bin mir sicher, dass wir mehr Geschäftslogik aufbauen werden, wenn wir tiefer in die Entwicklung gehen). Momentan erstelle ich für jeden UI-Bildschirm, den ich erstelle, eine Modellklasse, eine Dienstklasse, eine DAO-Klasse, einen Controller (im Wesentlichen Servlet) und eine Menge JSP-Seiten. In den meisten Fällen ruft die Serviceklasse nur die Methoden von DAO auf, um Modellobjekte zu übergeben. Im Wesentlichen verwenden wir Modellklassen, um Daten von UI-Bildschirmen zuzuordnen. Daher werden die Modellobjekte vom Controller beim Senden eines Formulars ausgefüllt. Ich habe begonnen, Dienstklassen zu verwenden, um eine Trennungsschicht von der Netzschicht zur DAO-Schicht beizubehalten. Aber manchmal habe ich das Gefühl, dass die Serviceklasse nur unnötige API-Aufrufe hinzufügt. Ich würde denken, dass ich das DAO einfach in den Controller einschleusen und die Aufgabe schneller erledigen könnte. Ich möchte die Serviceklasse nur verwenden, wenn zusätzliche Geschäftslogik ausgeführt werden soll. Wenn Sie eine Anwendung entwerfen müssen, welche Faktoren berücksichtigen Sie Controller-> DAO vs Controller-> Service-> DAO-Kontrollfluss?

Answer 1

DAOs sind detaillierter und befassen sich mit einer bestimmten Entität. Dienste bieten Funktionen auf Makroebene und können mehr als ein DAO verwenden. In der Regel werden Dienste zum Definieren von Transaktionsgrenzen verwendet, um Atomarität zu erhalten. Mit anderen Worten: Wenn Sie mehrere Tabellen mit mehreren DAOs aktualisieren, können Sie mit der Definition der Transaktionsgrenze beim Service alle an die Datenbank vorgenommenen Änderungen festschreiben oder rückgängig machen.

In Ihrem Entwurf, da Sie für verschiedene Entitäten in erster Linie CRUD tun, kann es scheinen, dass Dienste, die nicht viel Wert hinzufügen. Stellen Sie sich jedoch das webbasierte Frontend als eine Möglichkeit vor, Daten zu aktualisieren. Nutzung von Diensten ermöglicht es Ihnen, dieselben Funktionen als Web-Service später auf andere Formen von Client wie Dritten Integratoren zu belichten, usw.

So in der Zusammenfassung, Ihr Design scheint mit herkömmlichen Vorgehensweisen im Einklang zu sein. Wenn Sie der Meinung sind, dass Sie mehrere Services zu einem gemeinsamen Thema kombinieren können, um den Overhead des Codes zu reduzieren, sollten Sie dies tun. Am Ende des Tages besteht das ultimative Ziel darin, einen wartbaren Code zu erstellen, den niemand zu ändern braucht, wenn Bedarf entsteht.

Answer 2

ich meine Antwort verweisen würde here

Die lange Rede kurzer Sinn der Vorteil ist, eine Service-Schicht zu verwenden, ist es gibt Ihnen Raum in die Zukunft zu verschieben, wenn Sie etwas mit Spring Security tun wollen und Rollen usw. Es erlaubt Ihnen, Transaktionen atomarer zu handhaben und Spring selbst hat wirklich schöne Anmerkungen dazu.

Answer 3

eine Serviceklasse verwenden, wenn sie mit mehr als einem aggregate root zu tun.

Inject Repositories (auch bekannt als ein dao, die eine Auflistung zurückzugibt) oder dao die direkt in der Steuerung, keine Notwendigkeit für eine zusätzliche Schicht/Klasse eines grundlegenden get zu tun.

Verwenden Sie nur Serviceklassen notwendig, wo sonst hat man doppelt so viel Code, je nach Bedarf.

Sie können Repository-generic und annoatoate mit @Transactional(propagation = Propagation.REQUIRED) erstellen, die erzwingt, dass eine Transaktion vorhanden ist, aber keine neue erstellen, wenn sie bereits vorhanden ist. Wenn Sie also in einer Serviceklassenmethode zu einem späteren Zeitpunkt mehrere Repositorys verwenden, haben Sie nur die eine Transaktion.

Answer 4

In Pro-Spring-3 Buch, das sie unter der Linie erwähnt, für Regler mit JPA2

Once the EntityManagerFactory had been properly configured, injecting it into your service layer 
classes is very simple. 

und sie werden unter Verwendung der gleichen Klasse wie Service und Repository wie in unten:

package com.apress.prospring3.ch10.service.jpa; 
// Import statements omitted 
@Service("jpaContactService") 
@Repository 
@Transactional 
public class ContactServiceImpl implements ContactService { 
private Log log = LogFactory.getLog(ContactServiceImpl.class); 
@PersistenceContext 
private EntityManager em; 
// Other code omitted 
} 

aber falls Sie feder Daten CRUDRepository oder JPARepository verwenden werden dann Ihre DAO-Schnittstelle sein und Sie müssen Service-Layer machen Ihren Code zu behandeln