Amigos,
de voces que ja trabalharam ou trabalham com UML, quando vou fazer a analize de um projeto com diagrama de classes, nesse diagrama eu coloco so minhas classes entity ou tam bem minhas classes de controle e interface vao fazer parte desse diagrama?
obrigado
ué, todas.
tranquilo, é que to estudando UML e geralmente so vejo exemplos em que mostram as classes de entidades se relacionando, nenhuma classe de view ou controller e mostrada.
Uma outra duvida, mas agora mais a nivel de programaçao de 3 camadas. Muitos exemplos que vejo nos dizem para usar um JSP como interface, mas me repondam uma coisa, uma JSP se torna um servlet ao ser compilada, entao eu posso usar um sevlet como interface e um outro servlet por exemplo como classe de controle, nao posso?
Ola, Paulo,
UML é uma linguagem,como Java, C++, Português… você deve decidir o que é melhor fazer com ela, não existem regras “oficiais” sobre isso.
Sobre diagramas de classes:
1 - Documente só o que for importante
2 - Nunca crie um diagrama que pode ser criado automaticamente (com engenharia reversa) quando precisar
3 - Evite criar diagramas de classes para doicumenta sites e interfaces, existem tecnologias melhores
Sobe camadas, sim, você pdoe usar qualquer coisa como view e qualquer coisa como controlador, o que define o papel não é a tecnologia usada, mas a responsabilidade do componente.
Não se esqueça que a parte MVC da sua aplicação é apenas uma estruturação da camada de apresentação, você ainda deve definir uma camada de negócios e persistência.
[quote=“pcalcado”]Ola, Paulo,
Não se esqueça que a parte MVC da sua aplicação é apenas uma estruturação da camada de apresentação, você ainda deve definir uma camada de negócios e persistência.[/quote]
valeu pelos esclarecimentos pcalcado!
Mas isso ultimo que voce falou é que me deixou curioso, ate bem pouco tempo eu via uma relaçao direta entre 3 camadas e MVC, ate que comecei a ler alguns topicos aqui e com isso que voce falou fiquei ainda com mais duvida.
Entao MVC é parte da programaçao em 3 camadas? Se nao for pedir muito sera que voce poderia me explicar melhor?
obrigado!
Uma camada é um agrupamento lógico de componentes com responsabilidade similar. Existem várias camadas, cada aplicação pode definir um número qualquer, é dever do projetista não criar camadas demais nem de menos.
As famosas três camadas, Apresentação, Negócios e Persistência, são onipresentes, quase toda aplicação vai te-las.
Dentro das camadas, podem existir outras divisões lógicas, que seriam espe´cies de subcamadas. Na sua camada de negócios, você poderia ter subcamadas para gestão de usuários, workflow… a camada de persistência pode estar dividida em duas, cada uma persistindo objetos em um banco de dados diferentes.
Na camada de apresentação, uma p´ratica comum é separar em View (janelas, páginas, telas…), Controller (respondem ao que acotneceu na tela) e Model (regras de negócio). O Model do MVC é uma interface para a camada de negócios.
No Conexão java 2005 - www.conexaojava.com.br - eue starei apresentando um minicurso sobre o tema. Se você não puder comparecer, depois os slides e material de apoio estarão disponíveis em www.fragmental.com.br 
[quote=“pcalcado”]
Na camada de apresentação, uma p´ratica comum é separar em View (janelas, páginas, telas…), Controller (respondem ao que acotneceu na tela) e Model (regras de negócio). O Model do MVC é uma interface para a camada de negócios.
No Conexão java 2005 - www.conexaojava.com.br - eue starei apresentando um minicurso sobre o tema. Se você não puder comparecer, depois os slides e material de apoio estarão disponíveis em www.fragmental.com.br ;)[/quote]
Humm, entendi mas ainda estou com uma duvida, quando se fala em MVC, fala-se de JDBC e EJB para o Model, eles tambem nao estariam na camada de persistencia, claro que no caso de EJB seria os entity beans. E o Controller ele nao é considerado da classe de negocios? Pois achava que na camada de apresentaçao nao haveria nenhuma logica. Desculpa esta sendo insistente, mas é que realmente gostaria de enetender isso.
ah, obrigado pelo convite, mas infelizmente nao poderei participar, mas estarei aguardando o material de apoio que com certeza sera de muita ajuda.
Teoricamente para aplicações muito simples, você pdoeria colocar sua lógica de negócios no controlador. Eu não gosto dessa prática e acho que nessas aplicações o ideal é você não utilizar JEE, mas sim alternativas como Ruby on Rails ou PHP.
Partindo do ponto que sua aplicação não é tão simples, antes de mais nada esqueça EJBs. Eles foram vendidos como “o melhor de JEE”, mas tudo não passa de marketing, tanto que a evolução para o EJB 3.0 rpaticamente reescreveu tudo do zero.
A sua lógica de negócios pode muito bem ser implementada com POJOs, classes java normais. O seu controlador (suas “Actions”) entram em contato com a camada de negócios (geralmente por um Façade), eles não executam lógica de negócios nenhuma.
A lógica do controlador está em saber para quem despachar as requisições para o lugar certo e saber transformar as respostas em algo para ser exibido na interface (isso é uma limitação do HTTP, num modelo MVC puro a view se atualiza sozinha).
[quote=“pcalcado”][quote=“paulokarol”]
Humm, entendi mas ainda estou com uma duvida, quando se fala em MVC, fala-se de JDBC e EJB para o Model, eles tambem nao estariam na camada de persistencia, claro que no caso de EJB seria os entity beans. E o Controller ele nao é considerado da classe de negocios? Pois achava que na camada de apresentaçao nao haveria nenhuma logica. Desculpa esta sendo insistente, mas é que realmente gostaria de enetender isso.
[/quote]
Teoricamente para aplicações muito simples, você pdoeria colocar sua lógica de negócios no controlador. Eu não gosto dessa prática e acho que nessas aplicações o ideal é você não utilizar JEE, mas sim alternativas como Ruby on Rails ou PHP.
Partindo do ponto que sua aplicação não é tão simples, antes de mais nada esqueça EJBs. Eles foram vendidos como “o melhor de JEE”, mas tudo não passa de marketing, tanto que a evolução para o EJB 3.0 rpaticamente reescreveu tudo do zero.
A sua lógica de negócios pode muito bem ser implementada com POJOs, classes java normais. O seu controlador (suas “Actions”) entram em contato com a camada de negócios (geralmente por um Façade), eles não executam lógica de negócios nenhuma.
A lógica do controlador está em saber para quem despachar as requisições para o lugar certo e saber transformar as respostas em algo para ser exibido na interface (isso é uma limitação do HTTP, num modelo MVC puro a view se atualiza sozinha).[/quote]
obrigado pelos esclarecimentos, mas outra duvida:
ok, entao meu Controller vai entrar em contato com minha camada de negocio e vai saber pra que despachar as requisiçoes e ao receber sabera como exibir no view (so uma rapida duvida, posso ter algum tipo de validaçao aqui?). Mas onde entra o Model? Nao estou conseguindo ver…
Pode (e deveria) haver validação, só cuidado com duplicação de código que pdoe ser evitada.
Imagina a seguinte interface:
interface GerenciadorUsuarios{
public list listarUsuarios();
public void adicionarUsuario(Usuario u);
}Essa interface pertence à camada de negócios.
O seu AdicionarUsuarioAction iria chamar o método adicionarUsuario passando como parametro um objeto usuario que ele construiu com o que veio no request.
O ListarUsuariosAction chama o metodo listarUsuarios(), pega a lista que este retorna, coloca em escopo de request e faz um foward pra JSP…
E por ai vai