Ola amigos estou com uma duvida.
Tenho um diagrama de sequencia Cadastrar Setor e queria saber o que vem depois da camada controle se e a camada Dao (Data Access Object) ou model.
Veja o meu diagrama se esta correto por favor.
Obrigado.
Camadas são um agrupamento de classes
O DAO sozinho não é uma camada. Ele faz parte da camada de persistência assim como o seu Model.
Se o seu modelo for anêmico, ou seja, o model apenas carrega os atributos pra la e pra ca, então o DAO vai fazer, tipicamente, coisas demais.
Vc pode ter uma abordagem mais Orientada a Objetos (DDD) e seus objetos terem mais significado (como ser capaz de validarem a si mesmos, etc). Ou eles podem substituir o DAO (padrão ActiveRecord). São muitas possibilidades
Pense assim: seus objetos existem enquanto há memoria e eletricidade. Como vc quer extender essa durabilidade, vc usa um banco de dados.
MVC é sobre agrupar classes de acordo com a função delas.
Grande Peczenyj obrigado pela ajuda mas então o que eu fiz ta certo?
Não faço ideia.
mas acho estranho a primeira interação de volta ser “Dados Cadastrados com Sucesso”
sendo q o Setor não cadastra, quem cadastra é o DAO
como vc valida o Setor? vc tem setores fixos ou isso esta cadastrado no banco de dados?
Nesse caso, o correto seria MAS, sinônimo de porém e não MAIS, quantitativo.
Vamos lá: onde você instancia e utiliza o objeto da classe Setor? Depois que ocorreu a persistência no banco de dados?
O diagrama de sequência visa definir, passo a passo, todas as etapas (todas é um exagero, apenas as principais) da execução de uma determinada ação em teu sistema, como a inclusão de um novo registro.
É dessa maneira que você precisa pensar.
Sobre o que o @peczenyj disse, ele está dando uma sugestão de abordagem que provavelmente vai além do que você já aprendeu. Foque no que você já viu e siga isso, não invente, faça o simples primeiro, depois vá evoluindo (muito embora o simples seja adotar uma outra abordagem, como ele sugeriu).
@peczenyj posso então retornar como true a mensagem que vem do modelo Setor retornando para o DAO?
Já que vc disse q quem cadastra e a dao.
E o modelo Setor possui um método de validação de campos para não deixar o campo vazio.
Se o codigo compilar, vc pode.
A questão é: vc deve?
Existem diversas formas de validar dados e vc pode adotar estratégias redundantes.
Vc não vai inserir dado errado no banco por conta das constraints, do dao, do model, da view que filtra e valida algumas coisad. Comece simples
@peczenyj cara eu tava validados os campos no Controle mas o pessoal começou a dizer q estava errado validar campos no controle e sim tinha que validar os campos na model
Se está seguindo a arquitetura MVC, a validação é no model. Controller é só meio de campo.
Independente do que seguir, tenha uma classe separada que seja responsável pela validação.
Não entendi pq está precisando fazer esse diagrama, se for trabalho de faculdade ok.
Dependendo do problema vc pode validar fora do model.
Tipo uma view que obriga o cara prencher e-mail, valida o format, etc.
Mas isso é uma estratégia de user experience + performance, quando vc quer evitar lidar com requisições erradas.
Quando vc lida com poucos acessos de poucas pessoas pode ser irrelevante. Pra um volume brutal ai pode ser interessante
Por isso eu evito ser rígido demais. Por outro lado sempre q vc sai do lugar comum vc pode ter muito mais problemas. Como vc explica pra outros programadores o q vc fez? Ta todo mundo esperando um MVC e ai alguem inventa um outro modelo, que é nanossegundos mais rápido porem complicado de entender?
Programar é controlar a complexidade.
Se vc tem dúvidas, tente varias formas. É bom pro nosso senso crítico.
Eu não tenho como ajudar em relação a esse diagrama pois nunca nem vi isso sendo usado, mas se tiver alguma dúvida específica sobre a implementação é só falar.
Como está o caso de uso?
Entendo que seja algo como:
- usuário acessa a tela de login
- sistema carrega tela de login
- usuário preenche os dados de login e clica em login
- sistema valida dados do login
- sistema retorna mensagem “Usuário logado com sucesso!”
- fim do caso de uso
Certo?
Agora, a classe Usuario possui um método chamado validaLogin, sem parâmetros?
Onde instancia um objeto dessa classe?
Sim @darlan_machado só que eu esqueci de passar o método como boolean pq estou implementando em java ok!!!
Na Uml ficaria assim validaLogin() :Boolean.
Haaa sim o objeto é Usuario : usuario, mas isso não é opcional declarar desta forma no Diagrama de Sequência mas não posso declarar como somente Usuario?
Cara, eu entendo que, quando você não nomeia o objeto, está usando um objeto anônimo. Mas é o meu entendimento.
No meu ponto de vista, o ControleLogin e o controleCadastrarSetor são como Facade para os models da aplicação, portanto eles também fazem parte do modelo. No JSF, não se programa a camada de controle, todas as classes são modelos e as views são os xhtml, a camada de controle é de responsabilidade do framework, e no SpringMVC é quase a mesma coisa.
Se for projeto Desktop, a camada de controle somente faria a navegação das telas e guardaria os recursos e instâncias (sessão):
class Tela extends JFrame {
Action action;
Model model;
JButton button;
public Tela() {
button.addActionListener({
model.executarTarefa();
action.executar(resultado);
});
}
}
class Controle {
Model model;
Tela tela1;
public Controle() {
tela1.setAction((resultado){
if resultado == "Sucesso" {
tela1.setVisible(false);
tela2.setModel(outroModel);
tela2.setVisible(true);
}
});
}
}
É muito relativo, mas na minha opinião, o nome não pode ser controle e o setor não deveria se alto validar, deveria criar uma outra classe para validação.
Qual a necessidade de criar o diagrama de sequência?
É provável que sejam desnecessários, pois não vejo complexidade na sequência das mensagens ou no comportamento. Mesmo que vc decida criar outros diagramas de sequencia, acredito que todos serão parecidos um com outro, provando ainda mais a desnecessidade deles. Recomendo que só faça isso para tarefas complexas, evitando para cadastros e login.
Cite a fonte dessa declaração, pois não vejo sentido algum nisso, são qualquer coisa, menos modelos, ainda mais se considerarmos estas definições.
Ok, quer uma definição melhor, lá vai:
Eu me refiro ao JSF, não achei sobre isso nos links que vc postou, não achei a fonte que eu li isso pois foi a muito tempo e era um site da Sun. Lembro que estava escrito que o ManagedBean fazia parte do modelo, se isso é verdade então o que seria o Controller no JSF? Poderia dar um exemplo?
Opa, preciso admitir que foi erro meu.
Segundo pode ser visto neste artigo, realmente você está certo e o managed bean é um componente da camada model, responsável pela lógica de negócios.
O controller é o próprio framework.
Segue https://www.tutorialspoint.com/jsf/jsf_architecture.htm