Service-Layer in Java Swing Anwendung

StackOverflow https://stackoverflow.com/questions/4270461

Frage

Ich denke, wenn ich wirklich eine Service-Schicht benötigen.

Ich bin mit Feder + für eine Desktop-Swing-Anwendung überwintert und in diesem Moment i gui habe / schwingen Schicht-> Service Layer-> dao Schicht. Ich benutze Feder nur für @Transactional Unterstützung und für IOC-Injektion

Aus der Praxis sagen, dass ich einen Dienst zu schreiben, meine daos zu verwenden, und setzt alle Transaktionen Management im Service.

Aber ich bin zu erkennen, dass sehr, sehr oft, Service-Schicht nur replizieren dao Methoden, so zum Beispiel: 

// a DAO example
@Repository
public class CustomerHibernateDAO extends BaseHibernateDAO implements CustomerDAO {

 public List<Customer> findAllCustomerILikeName(String name){
  return getSession()
   .createCriteria(Customer.class)
   .add(Restriction.ilike("name", name))
   .list();
 }
}

// Customer service to use this dao...
@Service
@Transactional
public class CustomerService {

 @Autowired
 CustomerDAO customerDAO;

 // Why i can't call DAO instead the service?
 public List<Customer> getAllCustomersByName(String name){
      return customerDAO.findAllCustomerILikeName(name);
 }

}

Dies ist eine Mine typische Nutzung von Service-Layer ... Hibernate ist db-agnostisch, Frühling ist tecnology-agnostisch: so, ich brauche es wirklich

Was ist mit einer einzigartigen Service-Klasse alle DAO verwalten ?? Ich denke, dies ist ein guter Kompromiss sein kann, oder eine schlechte Praxis ist?

Ich weiß setzen @Transactional auf DAO ist eine schlechte Art und Weise, aber in diesem Moment habe ich zu schreiben Dienste nur für setzen @Transactional drauf ...

Bearbeiten

Mehr Infos über meine App.

Meine Anwendung ist eine Management-Software und Benutzerregistrierung verwalten, Produkte, Ordnung und andere Dinge wie diese. In der Praxis enthält es eine Menge Lese entity> Bearbeiten-> speichern Einheit oder CREATE-> Bearbeiten-> Speichervorgänge, und dank überwintern, werden diese Operationen durch ONE dao die meiste Zeit geschafft, becouse Hibernate mit @manyto. .. Sammlung und cascade.save_update Genehmigungen speichern zwei oder mehr Einheiten in derselben bestehen Betrieb.

So zum Beispiel in meinem Artikel JFrame, wo ich einfügen, bearbeiten oder einen Artikel erstellen (ein Produkt zu verkaufen) gibt es: 

public ItemFrame(){
 // the constructor
 itemService=springAppContext.getBeans(ItemService.class);
}

public boolean validateForm(){
 // test if the gui is correctly filled by user
}

public boolean save(){
 // create an Item entity taking value from swing gui(JTextField etc)
 Item item=new Item();
 item.setName(nameTextField.getText());
 item.setEtc...
 // ItemService ' save method is a wrap around itemDao.save(item)...
 itemService.save(item);
}

private void saveItemActionPerformed(ActionEvent evt){
 // When i press SAVE button
 if(validateForm()){
  save();
 }
}

Das ist, was ich in den meisten Fällen, so dass ich glaube, ich fiel in anämisch-domain-Antipattern ...

Danke.

War es hilfreich?

Lösung

Wenn Sie Ihre Service-Layer-Duplikate dao, verwenden Sie Service-Layer überhaupt nicht. Ich habe den gleichen Fehler in einigen meiner Anwendungen, ich habe mich gefragt, „warum die Service-Layer-Looks so hässlich, und ist duplicationg DAO“ ...

Die Service-Ebene für Ihre Appliacation sein Schnittstelle sollte dieser doest bedeutet, dass einige Methoden sind nicht die gleiche in dao und in Service, aber der Hauptteil ist signifikant unterschiedlich. Das kann ich nicht sagen, ohne den Rest des Codes zu sehen, aber Ihre Frage (das ist fast das gleiche wie vor meine Fragen wenigen Monaten waren), so scheint es mir, dass Sie verwenden anämischen Domänenmodell Antipattern . In anämischem Domänenmodell, das Modell nur Felder und Getter enthält, keine wirklichen Methoden (Verhalten), die grundlegende objektorientierte Prinzipien (Objekt == Daten + Verhalten) verletzt ... Ihr Verhalten ist wahrscheinlich in etwas, das aussieht wie Transaktionsskript in Dienst Schicht, soll aber in Ihrem Modell (Domain-Schicht) sein.

Die Art und Weise dies aus ist reich Domain-Modell zu verwenden (Bohnen Modell über @Configurable injizierten). Sie können sagen, dass dies die Schichten Muster verletzt und Sie werden wahrscheinlich richtig sein. Aber ich bin davon überzeugt, dass wir über unsere Anwendung denken sollen (Domain + dao + Service) als Einzelkomponente (siehe Alistair Cockburn

Andere Tipps

An einem gewissen Punkt, Ihre Anwendung wird einig Business-Logik will. Außerdem sollten Sie die Eingabe, um sicherzustellen, zu bestätigen, dass es nicht etwas Böses oder notleidend angefordert wird. Diese Logik gehört in Ihrer Dienstschicht.

Darüber hinaus kann es möglich sein, Ihre DAO recht generisch zu machen, so dass Sie nur eine oder zwei Methoden, die nicht viel ändern. Dies reduziert das Risiko von etwas schrecklich falsch zu Ihren DAO-Klassen zu tun, jedesmal wenn Sie wollen, um die Funktionalität der App hinzufügen / ändern.

Die DAO ist für Zugangsdaten ein. Der Service ist für Business-Logik. Halten Sie sie trennen, und Sie werden auf lange Sicht glücklicher sein.

Schließlich müssen Sie das Verhalten von mehreren DAOs koordinieren. (: Nicht aktualisieren [diese], wenn [das] ist in einem bestimmten Zustand ex) Sie können auch eine gewisse Komplexität auf Ihre Geschäftsregeln einführen. Hier wird die Service-Schicht praktisch ist.

sagte, dass, gibt es „technisch“ nichts falsch mit der Service-Schicht gänzlich zu eliminieren. Es wird nur ein wenig mehr schmerzhaft sein, wenn Sie schließlich entscheiden, dass man einen braucht.

Statt Durchsetzung 

ui -> service -> DAO

für jeden Betrieb, Prüfung der Frage, beide 

ui -> DAO
ui -> service -> DAO

wobei letztere für komplexere Operationen verwendet

Nicht verbunden mit StackOverflow
scroll top