couche de service en application java swing

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

Question

Je pense si je vraiment besoin d'une couche de service.

J'utilise le printemps + mise en veille prolongée pour une application swing de bureau et en ce moment j'ai IUG / Swing Couche-> Service Couche-> dao couche. J'utilise printemps seulement pour le soutien et @Transactional pour injection du CIO

Le meilleur exemple de la pratique que je dois écrire un service à utiliser mes taos et de mettre toutes les opérations de gestion dans le service.

Mais je me rends compte que très souvent, la couche de service uniquement répliquées méthodes dao, donc par exemple: 

// 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);
 }

}

Ceci est une mine utilisation de la couche de tipical services ... Mise en veille prolongée est db-agnostique, le printemps sont tecnologies agnostique: donc, je l'ai vraiment besoin

Qu'en est-il une classe de service unique pour gérer l'ensemble OAC ?? Je pense que cela peut être un bon compromis, ou, est une mauvaise pratique?

Je sais mettre @Transactional sur DAO est une mauvaise façon, mais en ce moment je dois services d'écriture seulement pour mettre @Transactional sur elle ...

EDIT

Plus d'infos sur mon application.

Mon application est un logiciel de gestion et de gérer l'enregistrement des utilisateurs, les produits, l'ordre et d'autres choses comme celles-ci. Dans la pratique, il contient beaucoup de lecture Entité-> Edition-> Enregistrer entité ou create-> Edition-> opérations de sauvegarde, et, grâce à hiberner, ces opérations sont gérées par l'ONE dao la plupart du temps, becouse mise en veille prolongée avec @manyto. .. collecte et permet cascade.save_update d'économiser deux ou plusieurs entités de la même opération persistent.

Ainsi, par exemple, dans mes articles JFrame où je peux insérer, modifier ou créer un élément (un produit à vendre) il y a: 

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();
 }
}

est ce que j'ai dans la plupart des cas, donc je pense que je suis tombé dans anémiques domaine ... antimodèle

Merci.

Était-ce utile?

La solution

Si vos doublons de la couche de service Dão, vous n'utilisez pas la couche de service du tout. J'ai fait la même erreur dans quelques de mes applications, je me demandais « pourquoi les regards de la couche de service si laid, et est duplicationg OAC » ...

La couche de service doit être interface pour votre appliacation, cette doest moyenne, que certaines méthodes ne sont pas les mêmes dans dao et en service, mais la partie principale est sensiblement différente. Je ne peux pas dire cela sans regarder le reste de votre code, mais votre question (ce qui est presque le même que l'étaient il y a quelques mois, mes questions), il me semble, que vous utilisez modèle de domaine anémique antimodèle. Dans le modèle de domaine anémique, votre modèle ne contient que des champs et des apporteurs, aucune méthode réelle (comportement), ce qui constitue une violation des principes orientés objet fondamental (objet == données + comportement) ... votre comportement est probablement quelque chose qui ressemble à script de transaction en service couche, mais devrait être dans votre modèle (couche de domaine).

La sortie de ce modèle est d'utiliser riche de domaine (haricots injectés dans le modèle par l'intermédiaire d'@Configurable). Vous pouvez dire que cela viole le modèle de couches et vous serez probablement correct. Mais je suis convaincu que nous devrions penser comme une seule composante de notre application (domaine + dao + service) (voir Alistair Cockburn

Autres conseils

À un certain moment, l'application voudra une certaine logique métier. , Vous pouvez également valider l'entrée pour vous assurer qu'il n'y a pas quelque chose de mal ou improductifs demandé. Cette logique appartient dans votre couche de service.

De plus, il peut être possible de rendre votre DAO assez générique, de sorte que vous avez seulement une ou deux méthodes qui ne changent pas beaucoup. Cela réduit le risque de faire quelque chose de terriblement mal à vos classes DAO chaque fois que vous voulez ajouter / modifier la fonctionnalité de l'application.

Le DAO est pour les données d'accès. Le service est pour la logique métier. Gardez-les séparés et vous serez plus heureux à long terme.

Finalement, vous aurez besoin de coordonner leur comportement entre plusieurs de DAO. Vous pouvez également présenter une certaine complexité à vos règles métier (ex: ne mettez pas à [cette], si [que] est dans un état particulier). C'est là la couche de service est très pratique.

Cela dit, il n'y a rien de mal « techniquement » avec l'élimination de la couche de service tout à fait. Il sera juste un peu plus douloureux quand vous avez fini par décider que vous en avez besoin.

Au lieu d'appliquer 

ui -> service -> DAO

pour chaque opération, tenez compte permettant à la fois 

ui -> DAO
ui -> service -> DAO

ce dernier étant utilisé pour des opérations plus complexes

Non affilié à StackOverflow
scroll top