Nomes de classes em jsf

ManagedBean -> ClienteMB
Modelo -> Cliente (interface) ClienteImp (implementação)
Facade -> ClienteFacade (interface) ClienteImp (implementação)

Com JSF eu não uso VO pois você pode enviar sua classe para a tela e exibir tudo lah. Mas se for criar um VO para desacoplar, coloca ClienteVO que você será feliz. [=

legal o modo que vc usa, estou usando algo parecido.

vlw jake

alguem mais???

JSF -> ClienteMB = ClienteController ->ClienteImplement(modelo)

mausexdd:

jakefrog
facede seria o controller?

se for o meu é igual.

JSF -> ClienteMB ->ClienteController ->ClienteImplement(modelo)

Confesso que não entendo a diferença entre MB e Controller nesse caso,pra mim seria redudante.

Quando eu faço eu costumo usar o pattern

JSF -> MB -> Façade (Statales EJB) -> DAO (Statales EJB)

JSF + MB -> Controlam apenas dados exibidos nas telas, dialogs e textos. Não existe regra de negócio alguma.
Façade -> regras de negócio, processamentos e outras coisas
DAO -> regras das consultas (HQLs), e CRUD apenas. Não existe regra de negócio alguma.

Eu gosto dessas camadas pois fica tudo bem desacoplado e mais propenso a mudanças. [=

MAS, é gosto né? [=

jakefrog:

ManagedBean -> ClienteMB
Modelo -> Cliente (interface) ClienteImp (implementação)
Facade -> ClienteFacade (interface) ClienteImp (implementação)

Com JSF eu não uso VO pois você pode enviar sua classe para a tela e exibir tudo lah. Mas se for criar um VO para desacoplar, coloca ClienteVO que você será feliz. [=

gRoOve:

jakefrog:

ManagedBean -> ClienteMB
Modelo -> Cliente (interface) ClienteImp (implementação)
Facade -> ClienteFacade (interface) ClienteImp (implementação)

Com JSF eu não uso VO pois você pode enviar sua classe para a tela e exibir tudo lah. Mas se for criar um VO para desacoplar, coloca ClienteVO que você será feliz. [=

Por que você usa interface e implementação? Teria um exemplo?

Sua implementação fica menos acoplada, mais fácil de ser alterada, e no caso de EJB você já está com a interface pronta para ser enviada ao cliente.

jakefrog:

gRoOve:

jakefrog:

ManagedBean -> ClienteMB
Modelo -> Cliente (interface) ClienteImp (implementação)
Facade -> ClienteFacade (interface) ClienteImp (implementação)

Com JSF eu não uso VO pois você pode enviar sua classe para a tela e exibir tudo lah. Mas se for criar um VO para desacoplar, coloca ClienteVO que você será feliz. [=

Por que você usa interface e implementação? Teria um exemplo?

Padrão de projeto. Sempre programe para interface.

Sua implementação fica menos acoplada, mais fácil de ser alterada, e no caso de EJB você já está com a interface pronta para ser enviada ao cliente. ;)

Cara, na boa, isso fica redundante demais. O princípio de programar para interface não quer dizer que você tem que escrever uma interface para todos os tipos do seu sistema, signfica apenas que um objeto que usa uma classe não deve conhecer detalhes de implementação. Por exemplo, a sua classe de regra de negócio deve usar o DAO sem saber se ele sua JPA ou JDBC puro, mas se a sua aplicação não tem a perspectiva de suportar múltiplos provedores de persistência isso fica redundante.

rmendes08:

Cara, na boa, isso fica redundante demais. O princípio de programar para interface não quer dizer que você tem que escrever uma interface para todos os tipos do seu sistema, signfica apenas que um objeto que usa uma classe não deve conhecer detalhes de implementação. Por exemplo, a sua classe de regra de negócio deve usar o DAO sem saber se ele sua JPA ou JDBC puro, mas se a sua aplicação não tem a perspectiva de suportar múltiplos provedores de persistência isso fica redundante.

Poderia criar um factory onde você retorna apenas a interface do DAO sem precisar espalhar a implementação pelo seu código, ou a instanciação do mesmo.

Eu já li muitos livros falando isso cara e toda vez que precisei mudar meu sistema para polimorfismo, a mudança foi bem mais simples.

É gosto. [=

jakefrog:

rmendes08:

Cara, na boa, isso fica redundante demais. O princípio de programar para interface não quer dizer que você tem que escrever uma interface para todos os tipos do seu sistema, signfica apenas que um objeto que usa uma classe não deve conhecer detalhes de implementação. Por exemplo, a sua classe de regra de negócio deve usar o DAO sem saber se ele sua JPA ou JDBC puro, mas se a sua aplicação não tem a perspectiva de suportar múltiplos provedores de persistência isso fica redundante.

Não vejo desse modo. [=

Poderia criar um factory onde você retorna apenas a interface do DAO sem precisar espalhar a implementação pelo seu código, ou a instanciação do mesmo.

Eu já li muitos livros falando isso cara e toda vez que precisei mudar meu sistema para polimorfismo, a mudança foi bem mais simples.

É gosto. [=

Veja bem, não estou dizendo que desacoplar classes é ruim. Mas também não dá para escrever factories e interfaces para toda e qualquer classe do sistema. Isso é interessante quando você precisa comunicar camadas diferentes por exemplo, existem situações em que isso faz sentido e em outras situações o custo não compensa.

jakefrog você utiliza interface para todas as classes ou somente quando há a necessidade “na hora”?
Já que você tocou no assunto da interface da DAO, estou justamente com um problema relacionado a isso, no sistema que estou desenvolvendo criei uma classe DAO para cada classe Modelo (ClienteDAO, CarroDAO), ocorre que estou tendo que replicar todo o mesmo código(CRUD básico) por todas essas classes). O que eu poderia fazer neste caso? Consigo resolver somente com GenericDAO? Uma interfaces poderia ajudar em algo?

gRoOve:

jakefrog você utiliza interface para todas as classes ou somente quando há a necessidade “na hora”?
Já que você tocou no assunto da interface da DAO, estou justamente com um problema relacionado a isso, no sistema que estou desenvolvendo criei uma classe DAO para cada classe Modelo (ClienteDAO, CarroDAO), ocorre que estou tendo que replicar todo o mesmo código(CRUD básico) por todas essas classes). O que eu poderia fazer neste caso? Consigo resolver somente com GenericDAO? Uma interfaces poderia ajudar em algo?

Nesse caso, é interessante concentrar as funcionalidades comuns em um DAO genérico sim. Mas se você está usando JDBC puro esse trabalho pode ser bastante árduo, você vai acabar gastando mais tempo fazendo o DAO genérico do que a aplicação propriamente dita. Esse sim é um caso onde o uso de interfaces é interessante, assim o seu sistema fica flexível o suficiente para suportar refatorações na camada de persistência sem maiores traumas.

No momento estou utilizando a especificação JPA com implementação Hibernate para persistência.
Pra fazer o GenericDAO, ficaria mais ou menos assim:

class GenericDAO
class PessoaDAO extends GenericDAO
class CarroDAO extends GenericDAO

Seria interessante utilizar interface neste caso também?
Estou aprendendo a trabalhar com interfaces, não consigo visualizar a utilização numa “mudança” futura no sistema.