[quote=Rhyan]Boa tarde!
Pessoal, já vi vários posts sobre o MVC aqui no fóum porém gostaria de tirar minha dúvida de forma mais clara, sem arrodeios e explicações técnicas e de difíceis entendimentos.
Model - ?
View - ?
Controller - ?
Onde fica a classe com os comandos getteres e setters no modelo MVC?
Onde fica a classe com a conexão com o banco de dados no modelo MVC?
Onde fica a classe DAO, com os métodos de inserir, alterar, excluir, pesquisar os dados no banco de dados, no modelo MVC?
Os formulários ficam no View.
E se eu colocar imagens no meu projeto onde devo colocá-las no MVC?
Bem essas são as minhas dúvidas.
[/quote]
De forma clara e sem rodeios : Vc não percebe nada de MVC. Portanto, suas perguntas são vazias de significado e qualquer resposta é inconsequente. :evil:
Eu acho que deveríamos instituir uma multa para quem vier fazer perguntas deste tipo. Nem as 7 pragas demoraram tanto tempo para ir embora. :shock:
De forma lenta e com rodeios e explicações técnicas ( para os interessados)
Nomenclatura de pacotes :
Escolha como raiz de todos os pacotes o domínio invertido da sua empresa ou produto. por exemplo com.javabuilding para o dominio javabuiliding.com.
A partir dai é legar criar um pacote por camada. Mas isto não é uma regra. Os pacotes na realidade devem ser criados com base na responsabilidade das classes lá dentro e conforme as relações entre elas. Coisas como acesso privilegiado de pacote devem ser tomadas em consideração.
Não existe o pacote “view”. nem o pacote “model”, nem o pacote “control”.
No máximo vai existir um pacote de classes de ui chamado “ui” ou alguma coisa com ui no nome. Isto representa coisas que serão visíveis de alguma forma.
No ui temos o “presentation” e se refere a classes que dirigem a ui como os actions do struts, por exemplo. às vezes o pessoal chama conforme o framework, “actions” para struts, “managedbean” para jsf, etc…
Ai temos o pacote “domain” para entidades e repositorios. Pode ter um sub pacote “repositories” se necessário.
Ai temos o pacote “services”. Poderia ser “domain.services”, mas normalmente é só services. Mas se usar muitos serviços externos, é legal separar o que é service de outros e o que e do seu dominio. Também é possivel usar “services.external” para servicos de fora ou serviços de infra como email, por exemplo. costuma haver um pacote paras as implementações dos serivços algo criativo como “services.impl”
Ai temos o pacote “persistence” para dados e entidades persistentes . Aqui temos os subpacotes persistence.dao se necessário, mas hoje em dia, se está usando DAO provavelmente está fazendo errado.
Um outro modelo que eu já vi usar e é interessante embora exija entendimento do padrão ECB (100% das pessoas que falam de MVC como se fosse camadas estão falando de ECB, mas não sabem).
Aqui temos por andar e componente. então client.bondary , client.entity e cliente.control. , presentation.bondary, presentation.entity e presentation.control, etc… os outros andares são : domain, integration e resource. Normalmente o resource não vira um pacote porque é conceptual.
Outras coisas que tem que ser consideradas é o agrupamento disto em jar. Vários jar podem ter o mesmo pacote, mas normalmente as pessoas agrupam os pacotes no jars conforme o deploy. Isto era mais importante antigamente no ejb2 e quando ha remote envolvido porque o jar com as classes serializadas tem que existir dos dois lados da comunicação. Então por exemplo , se usar as entidades do dominio, o domain.entities e o services ira em um pacote para o cliente e o servidor, mas o domain.repository e o services.impl ficariam apenas no servidor. Aqui a arquitetura do sistema vai demandar a separação ou não dos pacotes. Para sistemas web simples, fica tudo no war mesmo.
No caso de web também podem exisitr tags especiais que ficariam em ‘ui.tags’ ou ‘ui.web.tags’. Imagens, javascript, css, e outras coisas que devem ficar acessíveis via browser, devem ficar directamente na raiz do war, e podem ficar em pastas. normalmente js para javascript e css para css e images para imagens (nomes muito originais).
Basicamente não ha regras que o java obrigue nem ha padrões comandando os nomes. É uma questão de bom senso e cultura e experiencia usar um esquema de nomes e pacotes ou outro. Mas nem ha necessidade de pacotes para começo de conversa, é que é uma coisa muito util na hora de procurar uma classe que não sabemos bem o nome mas sabemos mais ou menos a responsabilidade ou a camada em que fica.
O netdark3000 já cobriu o resto.