Olá a todos dos site.
Estou com uma dúvida a respeito de MVC e gostaria de saber se vcs fazem como eu ou se utilizam alguma outra solução.
Na orientação a objetos, uma classe deve ter seus atributos e métodos dentro dela. Mas isso não ocorre na maioria dos exemplos que vejo por ai.
Normalmente, quando utilizamos jpa apenas moldamos uma classe com atributos e nenhum método para aplicar lógica. A logica é aplicada dentro do controller.
Alguns autores chamam isso de classes anêmicas!!!
Isto funciona bem, mas não sei se é o correto.
Exemplo:
Modelo:
@Entity
public class Usuario {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(unique = true, nullable = false)
private int id;
@Column(nullable = false, length = 150)
private String nome;
@Column(nullable = false, length = 26)
private String senha;
//getters e setter
Controller:
@ManagedBean(name = "usuarioBean")
@SessionScoped
public class UsuarioBean {
private Usuario usuario = new Usuario();
public String salvar(){ //método para salvar usuario implementado no controller
UsuarioDAO dao = new UsuarioDAO();
dao.salvar(usuario);
return "sucesso"
}
//getters e setters
}
O Controller deve fazer a intermediação da sua view com as outras camadas, porém isto não significa que não existe regras de negocio implementadas nas suas classes modelo.
Um simples exemplo:
class Conta {
private double saldo;
private double limite;
public Conta(double limite) {
this.limite = limite;
}
public void deposita (double x) {
this.saldo += x;
}
public void saca(double x) {
if(this.saldo + this.limite >= x) {
this.saldo -= x;
}
else throw new IllegalArgumentException("estourou limite!");
}
public double getSaldo() {
return this.saldo;
}
}
No seu controller você deverá apenas tratar o retorno do metodo saca por exemplo
[quote=mausexdd]O Controller deve fazer a intermediação da sua view com as outras camadas, porém isto não significa que não existe regras de negocio implementadas nas suas classes modelo.
[/quote]
Concordo com vc e creio que este deva ser o comportamento correto do modelo MVC. Todavia estava explicitando em relação ao mapeamento com jpa de uma classe somente com seus atributos e grande parte da logica no controller. Como há em alguns exemplos por ai.
Compreendo. Porém percebe-se que realizando o mapeamento das classes modelo você está especificando algumas validações desta classe,como o objeto da mesma devera se comportar, porém utilizando notações JPA,
[quote=mausexdd]O Controller deve fazer a intermediação da sua view com as outras camadas, porém isto não significa que não existe regras de negocio implementadas nas suas classes modelo.
Um simples exemplo:
class Conta {
private double saldo;
private double limite;
public Conta(double limite) {
this.limite = limite;
}
public void deposita (double x) {
this.saldo += x;
}
public void saca(double x) {
if(this.saldo + this.limite >= x) {
this.saldo -= x;
}
else throw new IllegalArgumentException("estourou limite!");
}
public double getSaldo() {
return this.saldo;
}
}
No seu controller você deverá apenas tratar o retorno do metodo saca por exemplo [/quote]
As regras de negocio não deveriam ficar na classe para as regras de negocio? como no seu exemplo da conta seria ContaRN ?
[quote=Mathe][quote=mausexdd]
As regras de negocio não deveriam ficar na classe para as regras de negocio? como no seu exemplo da conta seria ContaRN ?[/quote]
Já vi esse tipo de exemplo, o qual cria um classe para criar a lógica(métodos) da classe. Enquanto em outra classe vc apenas mapeia os atributos, como eu fiz no primeiro post.
Depois no controle vc chamaria a ContaRN para aplicar os seus métodos na classe Conta.
Todavia, desse modo, estariamos quebrando o paradigma de OO, em que os atributos e os métodos pertencem a mesma classe, não?
Olha realmente, mas os pontos positivos de se usar esse padrão acho que sobrepoem essa regra que não vai mudar tanta coisa assim quando sabemos que na classe com o sufixo RN estão os métodos e na classe sem o sufixo está a classe mapeada.