Caros colegas, venho há alguns meses estudando sobre desenvolvimento web com JSF, Hibernate, Mysql e agora estou colocando em prática com um pequeno projeto, que servirá de base para uma aplicação que irei desenvolver.
A minha dúvida é em relação a separação das responsabilidades, isto é, o papel de cada classe e se a forma que estou fazendo esta correta.
Ela esta separada dessa forma (vou colocar apenas os trechos da classe, apenas para entendimento conceitual):
[color=green]Model[/color]
@Entity
public class Usuario {
private String nome;
// getters e setters
}
public class UsuarioDAOHibernate implements UsuarioDAO {
private Session session;
public void setSession(Session session) {
this.session = session;
}
public void salvar(Usuario usuario) {
this.session.save(usuario);
}
[color=green]Controller[/color]
// Não sei se o conceito de Service se aplica assim, esta correto?
public class UsuarioService {
private UsuarioDAO usuarioDAO;
public UsuarioService() {
this.usuarioDAO = DAOFactory.criarUsuarioDAO();
}
public void salvar(Usuario usuario) {
Integer codigo = usuario.getCodigo();
if (codigo == null || codigo == 0) {
this.usuarioDAO.salvar(usuario);
} else {
this.usuarioDAO.atualizar(usuario);
}
}
[color=red]Controller ou View?[/color]
@ManagedBean(name="usuarioBean")
@RequestScoped
public class UsuarioBean {
private Usuario usuario = new Usuario();
public String salvar() {
UsuarioService usuarioService = new UsuarioService();
usuarioService.salvar(this.usuario);
return "usuario";
}
@Entity
public class Usuario {
private String nome;
// getters e setters
}
public class UsuarioDAOHibernate implements UsuarioDAO {
private Session session;
public void setSession(Session session) {
this.session = session;
}
public void salvar(Usuario usuario) {
this.session.save(usuario);
}
[/quote=sudo]
Model
[quote=sudo]
[color=green]Controller[/color]
// Não sei se o conceito de Service se aplica assim, esta correto?
public class UsuarioService {
private UsuarioDAO usuarioDAO;
public UsuarioService() {
this.usuarioDAO = DAOFactory.criarUsuarioDAO();
}
public void salvar(Usuario usuario) {
Integer codigo = usuario.getCodigo();
if (codigo == null || codigo == 0) {
this.usuarioDAO.salvar(usuario);
} else {
this.usuarioDAO.atualizar(usuario);
}
}
[/quote=sudo]
Controller
[quote=sudo]
[color=red]Controller ou View?[/color]
@ManagedBean(name="usuarioBean")
@RequestScoped
public class UsuarioBean {
private Usuario usuario = new Usuario();
public String salvar() {
UsuarioService usuarioService = new UsuarioService();
usuarioService.salvar(this.usuario);
return "usuario";
}
[/quote=sudo]
View
[quote=sudo]
[color=green]View[/color]
<h1>Cadastro de Usuarios</h1>
<h:form id="cadastro">
<h:outputLabel for="nome" value="Nome:" />
<h:inputText id="nome" label="Nome" value="#{usuarioBean.usuario.nome}"/>
<h:commandButton value="Salvar" action="#{usuarioBean.salvar}" />
</h:form>
[/quote]
Detalhes:
Seguindo o modelo que você está pensando, você segue um modelo anêmico e abstrai, novamente, a camada de persistência. Embora eu ache esse modelo “mais legal”, há muita gente que prefere o proposto pelo Martin Fowler, ou seja, a responsabilidade da persistência deve ficar nas entidades (além de outras ações). Pense nisso.
[quote=drsmachado]
Seguindo o modelo que você está pensando, você segue um modelo anêmico e abstrai, novamente, a camada de persistência. Embora eu ache esse modelo “mais legal”, há muita gente que prefere o proposto pelo Martin Fowler, ou seja, a responsabilidade da persistência deve ficar nas entidades (além de outras ações). Pense nisso.[/quote]
Primeiramente obrigado pela resposta drsmachado, esse modelo é o que mais encontrei recomendações, mas eu particularmente acho ele muito “inchado” pois se vc reparar, vamos ver que declaro várias vezes a mesma coisa, como por exemplo o método Salvar. Segundo o que li isso garante o baixo acoplamento da aplicação, mas fico com muitas classes para administrar também, tornando a aplicação “inchada”.
Esse modelo proposto pelo Fowler, tornaria minha aplicação mais “compacta”? Como ficaria essas classes seguindo o modelo dele?
[quote=sudo][quote=drsmachado]
Seguindo o modelo que você está pensando, você segue um modelo anêmico e abstrai, novamente, a camada de persistência. Embora eu ache esse modelo “mais legal”, há muita gente que prefere o proposto pelo Martin Fowler, ou seja, a responsabilidade da persistência deve ficar nas entidades (além de outras ações). Pense nisso.[/quote]
Primeiramente obrigado pela resposta drsmachado, esse modelo é o que mais encontrei recomendações, mas eu particularmente acho ele muito “inchado” pois se vc reparar, vamos ver que declaro várias vezes a mesma coisa, como por exemplo o método Salvar. Segundo o que li isso garante o baixo acoplamento da aplicação, mas fico com muitas classes para administrar também, tornando a aplicação “inchada”.
Esse modelo proposto pelo Fowler, tornaria minha aplicação mais “compacta”? Como ficaria essas classes seguindo o modelo dele?[/quote]
Veja bem, o fato de você ter várias vezes criado um método chamado “salvar”, mas em classes diferentes, pode ter duas conotações, a certa e a errada.
A errada é quando você cria o mesmo método, com mesmo retorno e mesmos argumentos. Lembre-se que um dos objetivos da orientação a objetos é eliminar a duplicidade de código.
A certa é que cada vez que você criou um método chamado “salvar”, ele tenha sido criado em uma camada diferente, garantindo o baixo acoplamento e a alta coesão (uma classe deve ser a mais especialista possível e deve conhecer apenas o estritamente necessário de outras).
Pensando na proposta do Fowler, talvez você se livrasse da camada DAO. Mas, ainda assim, teria a camada model, o controller e a view.
[quote=drsmachado][quote=sudo][quote=drsmachado]
Seguindo o modelo que você está pensando, você segue um modelo anêmico e abstrai, novamente, a camada de persistência. Embora eu ache esse modelo “mais legal”, há muita gente que prefere o proposto pelo Martin Fowler, ou seja, a responsabilidade da persistência deve ficar nas entidades (além de outras ações). Pense nisso.[/quote]
Primeiramente obrigado pela resposta drsmachado, esse modelo é o que mais encontrei recomendações, mas eu particularmente acho ele muito “inchado” pois se vc reparar, vamos ver que declaro várias vezes a mesma coisa, como por exemplo o método Salvar. Segundo o que li isso garante o baixo acoplamento da aplicação, mas fico com muitas classes para administrar também, tornando a aplicação “inchada”.
Esse modelo proposto pelo Fowler, tornaria minha aplicação mais “compacta”? Como ficaria essas classes seguindo o modelo dele?[/quote]
Veja bem, o fato de você ter várias vezes criado um método chamado “salvar”, mas em classes diferentes, pode ter duas conotações, a certa e a errada.
A errada é quando você cria o mesmo método, com mesmo retorno e mesmos argumentos. Lembre-se que um dos objetivos da orientação a objetos é eliminar a duplicidade de código.
A certa é que cada vez que você criou um método chamado “salvar”, ele tenha sido criado em uma camada diferente, garantindo o baixo acoplamento e a alta coesão (uma classe deve ser a mais especialista possível e deve conhecer apenas o estritamente necessário de outras).
Pensando na proposta do Fowler, talvez você se livrasse da camada DAO. Mas, ainda assim, teria a camada model, o controller e a view.[/quote]
Eu poderia transferir então a camada DAO para a entidade Usuario?
[quote=sudo][quote=drsmachado][quote=sudo][quote=drsmachado]
Seguindo o modelo que você está pensando, você segue um modelo anêmico e abstrai, novamente, a camada de persistência. Embora eu ache esse modelo “mais legal”, há muita gente que prefere o proposto pelo Martin Fowler, ou seja, a responsabilidade da persistência deve ficar nas entidades (além de outras ações). Pense nisso.[/quote]
Primeiramente obrigado pela resposta drsmachado, esse modelo é o que mais encontrei recomendações, mas eu particularmente acho ele muito “inchado” pois se vc reparar, vamos ver que declaro várias vezes a mesma coisa, como por exemplo o método Salvar. Segundo o que li isso garante o baixo acoplamento da aplicação, mas fico com muitas classes para administrar também, tornando a aplicação “inchada”.
Esse modelo proposto pelo Fowler, tornaria minha aplicação mais “compacta”? Como ficaria essas classes seguindo o modelo dele?[/quote]
Veja bem, o fato de você ter várias vezes criado um método chamado “salvar”, mas em classes diferentes, pode ter duas conotações, a certa e a errada.
A errada é quando você cria o mesmo método, com mesmo retorno e mesmos argumentos. Lembre-se que um dos objetivos da orientação a objetos é eliminar a duplicidade de código.
A certa é que cada vez que você criou um método chamado “salvar”, ele tenha sido criado em uma camada diferente, garantindo o baixo acoplamento e a alta coesão (uma classe deve ser a mais especialista possível e deve conhecer apenas o estritamente necessário de outras).
Pensando na proposta do Fowler, talvez você se livrasse da camada DAO. Mas, ainda assim, teria a camada model, o controller e a view.[/quote]
Eu poderia transferir então a camada DAO para a entidade Usuario?[/quote]
DAO é um modelo de desenvolvimento que visa abstrair a camada de persistência. Porém, você já usa um framework ORM que realiza essa abstração.
Eu considero que utilizar os dois não é errado, deixa mais organizado. Porém, é uma decisão tua.
Eu penso que um carro não é responsável por “criar-se”. Alguém (um grupo de pessoas) é quem o faz. Da mesma forma que não é o paciente que se cadastra no sistema do hospital, alguém faz o cadastro por ele…
[quote=drsmachado]
DAO é um modelo de desenvolvimento que visa abstrair a camada de persistência. Porém, você já usa um framework ORM que realiza essa abstração.
Eu considero que utilizar os dois não é errado, deixa mais organizado. Porém, é uma decisão tua.
Eu penso que um carro não é responsável por “criar-se”. Alguém (um grupo de pessoas) é quem o faz. Da mesma forma que não é o paciente que se cadastra no sistema do hospital, alguém faz o cadastro por ele…[/quote]
Realmente, um Usuario criar um Usuario fica meio estranho mesmo. Já que trabalho com o Hibernate, não tenho a necessidade de ficar trabalhando com DAO’s, dessa forma decide colocar essa tarefa na minha classe UsuarioService, estaria correto dessa forma?
public class UsuarioService {
private Session session;
public UsuarioService() {
this.session = HibernateUtil.getSessionFactory().getCurrentSession();
}
public void salvar(Usuario usuario) {
Integer codigo = usuario.getUsuario();
if (codigo == null || codigo == 0) {
this.session.save(usuario);
} else {
this.session.update(usuario);
}
}
@RequestScoped
public class UsuarioBean {
private Usuario usuario = new Usuario();
public String salvar() {
UsuarioService usuarioService = new UsuarioService();
usuarioService.salvar(this.usuario);
return "usuario";
}
Cara, vai de seu gosto, muitas pessoas seguem restritamente o mvc, e outras o modificam, claro que respeitando o sua ideia básica…eu particularmente faço desse jeito com jsf/;
Crio quatro pacotes: modelo, controle, dao, view e util.
Com o conceito do mvc o pacote dao ficaria no model, e o view e controle nas respectivamente separações.
No pacote modelo deixo as classes de negócio, no controle deixo os managedbean, e no dao as classes de aceso e persistência, e no pacote view deixo as páginas, e no pacote util as configurações do hibernate e arquivos auxiliares.
Essa estrutura varia muito, mas pelo que vi ate agora é a mais usada pela galera…
Valeu…