Dúvida sobre divisão da aplicação

Domínio

[quote=sudo]
[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);
}

[/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

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>

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.

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?

sudo:

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.

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?

drsmachado:

sudo:

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.

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?

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.

Eu poderia transferir então a camada DAO para a entidade Usuario?

sudo:

drsmachado:

sudo:

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.

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?

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.

Eu poderia transferir então a camada DAO para a entidade Usuario?

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…

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";
	}

O DAO dentro da entidade, no Java não é muito comum.

ActiveRecord para Ruby faz isso.

user = User.new
user.name = 'nome'
user.save

O user.save persiste o novo User no banco.

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…