Organização física aplicação MVC

Programação Java
#1

Pessoal.

Existe algum padrão para organizar a estrutura de uma aplicação Java MVC.

Têm projetos que a divisão de camadas é feita somente em pacotes. Outros, são vários projetos dependentes divindo as camadas.

O que vcs sabem sobre isso ?

#2

O bom de você ter projetos separados é que se por exemplo a sua camada de visão rodar em um servidor
e a camada com o regras de negócio em outro então não há razão para você ter classes referentes a camada de visão
no servidor de negócio e vice versa então é mais fácil para estruturar o build da aplicação.

#3

[quote=marcosharbs]O bom de você ter projetos separados é que se por exemplo a sua camada de visão rodar em um servidor
e a camada com o regras de negócio em outro então não há razão para você ter classes referentes a camada de visão
no servidor de negócio e vice versa então é mais fácil para estruturar o build da aplicação.[/quote]

Mas, não existe algum padrão ou convenção de nomes ?

#4

[quote=efcjunior][quote=marcosharbs]O bom de você ter projetos separados é que se por exemplo a sua camada de visão rodar em um servidor
e a camada com o regras de negócio em outro então não há razão para você ter classes referentes a camada de visão
no servidor de negócio e vice versa então é mais fácil para estruturar o build da aplicação.[/quote]

Mas, não existe algum padrão ou convenção de nomes ?

[/quote]

Gente…
Não existe padrão. Cada um faz do jeito que entende ser melhor ?

Não acho nada no google sobre esse assunto.

Já vi alguns sistemas separados por projetos: client, client-web, core, server, server-web…Legal mas, o que representa cada um desses projetos ?

#5

Quase isso … Criar classes que iniciam com letra Maiuscula não é obrigatório em java, mas é uma convenção :slight_smile:
A ideia de separação de camadas em pacotes que eu saiba não exista padrão, mas, é uma boa pratica separar por camdas também.

na maioria dos projetos que eu passei vejo assim:

br.com.nomedaempresa.dao // daos
br.com.nomedaempresa.model // regras de negocio
br.com.nomedaempresa.utils // classes utils da vida
br.com.nomedaempresa.bean // beans

dependendo do projeto, pode haver separação por modulo, ficando:

br.com.nomedaempresa.nomedomodulo.dao // daos
br.com.nomedaempresa.nomedomodulo.model // regras de negocio
br.com.nomedaempresa.nomedomodulo.utils // classes utils da vida
br.com.nomedaempresa.nomedomodulo.bean // beans

se trabalhar com interfaces, geralmente:

br.com.nomedaempresa.dao // interfaces
br.com.nomedaempresa.dao.impl // implementação
br.com.nomedaempresa.model // interfaces
br.com.nomedaempresa.model.impl // implementação

quando se usa algum framework mvc, geralmente crio uma pasta chamada view na raiz da aplicação e salvo os jsp’s da seguinte maneira:

/view/nomedomoduloouentidade/list.jsp // view de listagem, busca, etc ...
/view/nomedomoduloouentidade/input.jsp // view para edição, deleção e criação

se algume souber de algo mais, favor complementar :smiley:

#6

Costumo hoje em dia, seguir este padrão:


src
 -br.com.empresa.projeto.model //regra do negocio
 -br.com.empresa.projeto.model.dao // dao, costumo deixar dentro do pacote model
 -br.com.empresa.projeto.model.entity // entidades, representação das tabelas
 -br.com.empresa.projeto.view // telas e classes respectivas, custom tags..
     -br.com.empresa.projeto.view.swing
     -br.com.empresa.projeto.view.desktop
     -br.com.empresa.projeto.view.aplet
     -br.com.empresa.projeto.view.jsp
 -br.com.empresa.projeto.view.controler // classes que gerencia uma tela ex: backbean do jsf, action..
 -br.com.empresa.projeto.vo // classes para transportar informações das entitis
 -br.com.empresa.projeto.io // layouts, escrita, leitura de arquivos, socket..
    -br.com.empresa.projeto.io.layout
    -br.com.empresa.projeto.io.ftp
    -br.com.empresa.projeto.io.ws
 -br.com.empresa.projeto.utils // classes úteis
#7

Muito legal a convenção de vocês.

Só me tirem uma dúvida: O backbean entra na camada controller ?

Posso fazer assim:

jsf -----> backbean ----> facade(regra de negócio) -----> dao ?

#8

[quote=efcjunior]Só me tirem uma dúvida: O backbean entra na camada controller ?
[/quote]

Bom, eu acho que vai de opinião de cada um. Eu vejo o jsf assim:
o jsf em si faz o papel do Controler, sendo que o backbean é a parte que vai chamar a sua regra de negocio ou facade(Model) porem o backbean é especifico de uma tela, tem metodos e classes especifico para redenrizar uma ou mais tela, na minha opinião ela faz parte da view tb por causa disso. Esta um pouco nos dois escopos do mvc, view e controler.
Eu prefiro colocar o backbean nos pacotes de view ou view.controler

Eu gostumo usar este ciclo que vc postou:
jsf -----> backbean ----> facade(regra de negócio) -----> dao
Quanto mas desacoplado as classes estiver eu acho melhor.

#9