Estou começando a estudar o padrão e estou com a seguinte dúvida baseada em um livro de exercícios UML.
O projeto é simples, é um cadastro de contas de luz, porém ele tem 2 métodos, um que busca a conta de menor valor e outro a de maior valor.
Qual a dúvida ?
Não estou usando a camada DAO, apenas criei a classe “Conta” na camada model, porém os métodos que buscam a menor e maior conta devem estar também dentro dessa classe ? Esses métodos seriam static, uma vez que eles são usados por todos os objetos do tipo “Conta” ou seriam de instância ?
Estou confuso quando a isso, o correto seria:
class Conta{
public… menorConta(){}
}
ou
class Conta{
public static … menorConta(){}
}
Ou nenhum desses ?
Se fossem operações de salvar, etc, eu afirmaria que seria de instância, porém esse de buscar menor e maior conta, conceitualmente até onde li, me confundiu se é de instância ou static.
Qual objetivo dessa classe Conta? O que vai ter dentro do método menorConta()? Se esse método for manipular atributos de uma instancia qualquer da classe, então não pode ser estático.
Se está querendo fazer uma consulta no banco de dados, crie uma classe separada para isso, algo como “ConsultaConta”. Não precisa criar mais camadas, isso faz parte do Model, pra organizar pode criar uma pasta “Consultas” (Model\Contas\Consultas). Seria bom dividir os models por assunto se o projeto for crescer.
O objetivo da classe Conta também é a de acessar a base de dados e retornar a conta de menor e a de maior valor.
No caso, ficaria como ? Métodos estáticos só para fazer isso ? Eu também acho que o que faz mais sentido é tirar esses métodos da classe Conta e colocar em outra Classe.
Ao criar uma classe ContaDAO fica mais claro para mim, pois ali eu inseria todos os métodos. Porém se pensar somente na classe Conta para acessar os dados queria saber qual seria a melhor solução.
Na verdade eu vi um vídeo no youtube sobre Java e MVC e a pessoa implementou com métodos estáticos, o que me deixou confuso no que é usado como padrão.
Nao é bom misturar responsabilidades, dá uma lida sobre SRP.
Costumo me orientar pelas funcionalidades, para “Consultar Maior Conta” vai ser necessário no model:
1 - Classe POJO que represente saída do resultado para a controller entregar a view. Pode até ser “Conta” se for um resultado genérico de Conta. Quando não for, dê um nome mais significativo para o resultado.
2 - E uma classe que seja responsável por executar a query no banco com a regra de negócio para obter a maior conta e retornar o POJO. No MVC, acesso a dados fica no Model, até pode criar outra camada, mas não precisa se no final das contas isso for apenas burocratizar. Na maioria dos casos basta organizar e dar nomes significativos para o negócio como falei no primeiro post.
Pode ser estático se não tiver nenhuma dependência da instancia. Tudo depende de como está estruturado o projeto, não leve isso como regra por causa de uma vídeo aula, cada equipe pode trabalhar de um jeito.
Fiz um trabalho com MVC durante o ano, o que eu gravei foi o seguinte:
Sobre o MVC, creio que a camada modelo deve conter apenas os modelos de armazenamento e geração de dados. No seu caso eu incluiria a Classe Conta e uma classe de Contexto de Banco de Dados.
Os metodos com todas as ações que seu sistema deve executar ficariam na camada de Controle.
A camada DAO é reSponsavel em acessar o banco de dados e retornar os dados para a camada CONTROLLER, que por sua vez faz o retorno a camada VIEW.
A MODEL contem os atributos e seus encapsulamentos.
Correto sobre Classe Conta e uma classe de Contexto de Banco de Dados no Model.
Controller só deve fazer o meio de campo entre a View e Model. Toda regra de negócio e acesso a dados devem ficar no Model.
Model : “Sempre que você pensar em manipulação de dados, pense em model. Ele é responsável pela leitura e escrita de dados, e também de suas validações.”
View : “Simples: a camada de interação com o usuário. Ela apenas faz a exibição dos dados, sendo ela por meio de um html ou xml.”
Controller: “O responsável por receber todas as requisições do usuário. Seus métodos chamados actions são responsáveis por uma página, controlando qual model usar e qual view será mostrado ao usuário.”
DAO é um padrão com objetivo de abstrair a persistência, isso não vem do MVC, apenas é sugerido para abstrair a persistência. Acesso a dados faz parte do Model, não obrigatoriamente precisando de outra “camada”, padrão ou se prender a sigla A ou B como no “bolovo” por exemplo. O que vai ser usado e como vai ser organizado o acesso a dados dentro do Model fica ao nosso critério, partindo do simples necessário.
No “model.contas” do colega acima ele pode ter simplesmente uma classe ConsultaContasPagar que vai retornar o resultado para a Controller. Se vai usar DAO ou outra coisa para buscar os dados no banco fica a critério dele. Na maioria dos casos as empresas usam um banco de dados, se tornando preciosismo e burocrático tais interfaces, pois DAO não é simplesmente colocar a sigla DAO no final da classe.
Vamos supor que o usuário preenche um formulário, a validação da entrada de dados fica na camada controller ? A camada controller, por sua vez, vai validar e passar para a model ou a checagem ocorrem na model ?
Exemplo: O usuário coloca uma data em um formato e clica em um botão cadastrar. A camada Controller implementa um ActionListener e recebe esse evento. Aí a camada controller pega os dados da camada view e checa passando os dados para a camada Model.
Validação é no Model. Controller só faz o meio de campo.
Controller recebe os dados do formulário e chama o Model para salvar esses dados. Se não forem válidos, o Model retorna as mensagens de validação para a Controller, que vai repassar para a View. Se forem válidos o Model salva no banco de dados sem nenhuma mensagem de validação no retorno.
