JSF + DDD : Is it correct to use the domain entities within the bean Managed?

Asked

Viewed 172 times

1

1 - In the DDD it is correct to let the domain objects be fed by the JSF through EL ?

   // classe da camada de dominio
   public class Cliente {
       private String nome;
       // getters e setters;
    }

   // bean ligado diretamente ao objeto de dominio
    #{bean.cliente.nome}

I ask why in ASP people use VM to feed user inputs and automapper to convert VM data into domain object.

2 - If this is allowed, in case I use CDI, I must inject these classes right up into managedBeans or the instance of it has q come from within the domain layer ( a service classes, for example )?

// usando cdi para injetar
@named
class Bean{

     @inject
     Cliente cliente;
}

or

@named
class Bean{

     Cliente cliente;

     Bean(){
        cliente = servico.getInstanciaCliente();
     }
}
  • I liked the question, I also find it very ugly to expose my domain entities in the view, I know that most applications with faces + CDI are built this way, even I’ve done it myself, but in action-projectsbased where I do not depend on JSF I make use of DTO’s so with the interfaces of my domain, usually my applications have 4 modules would be more or less an EJB where have my templates, repositories, and services an Ejbclient that has my DTO’s, @Local interfaces and objects serving the WEB module(.War) and the EJB(jar) and the . That nothing is more than the package of all modules.

  • Of course I can use DTO’s with faces too, but mine are immovable I mean, I have no set methods and this with faces does not roll, but I liked your question, I will leave the staff with good technical background in Ddds comment.

  • The problem is to do this mapping in hand neh.. The risk of forgetting something in maintenance eh huge.. I wouldn’t risk doing something without an automapper of life

  • But using dto in front seems to hinder both the insertion of business logic in services... In my view the q domain entities should apply in all rules within the domain.

  • 2

    I understand, is that in my case my screens are complex, the other day I was chatting with a gringo extamente what we are talking about now, where he told me that my DTO’s were an anti-pattern (a hack for my views), in fact I enjoy the use of DTO’s not only for immutability but also because I do not need to expose several entities to view, I have an object that can serve one or several screens and can be formed of various entities, In my EJB I make use of other Patterns as assemblers who do the dirty work of the entity conversion x DTO, but I confess that it is a little complex.

  • but everything is very separate.

  • 1

    Pze . was reading about assemblers tbm . I will breathe more of this matter to see it be absorbed by osmosis.. I have a brother q does DDD c ASP NET and uses view model .. it seems q is worth it

Show 2 more comments
No answers

Browser other questions tagged

You are not signed in. Login or sign up in order to post.