Dúvida em estrutura em MVC

Assuntos Gerais Agile
#1

Olá, estou fazendo meu TCC e estou em dúvida quanto a estrutura do projeto, cria três pacotes que são util, bussiness, control e model, em business coloquei as classes DAO, em control pus as actions, em model coloquei as classes mapeadas do banco e em util coloquei classes usadas em geral no sistema como o validador de CPF/CNPJ, hibernateUtil entre outras. Esse estrutura está correta?

Minha outra dúvida é quanto a uso de interface, não estou falando de telas do sistema, mas das interfaces que devem ser implementadas nas classes, isso é obrigatório faz parte do MVC e em quanto isso é util?

#2

eu acho que os DAOs pertencem a camada de model, as suas classes de serviço (que implementam regras de negócio) é que ficam com o business.

Quanto à duvida de interfaces, tem um post do ViniGodoy onde ele fala sobre isso. ele usa listas como exemplo, mas a idéia pode ser aplicada a qualquer caso.

http://www.guj.com.br/java/55387-quanto-list-x--new-arraylist-e-melhor-do-que-arraylist-x--new-arraylist

só mais 2 observações, que não consigo não comentar:

1 - você criou 4 pacotes, não 3.
2 - é business, não bussiness.

#3

[quote=digaoneves]eu acho que os DAOs pertencem a camada de model, as suas classes de serviço (que implementam regras de negócio) é que ficam com o business.

Quanto à duvida de interfaces, tem um post do ViniGodoy onde ele fala sobre isso. ele usa listas como exemplo, mas a idéia pode ser aplicada a qualquer caso.

http://www.guj.com.br/java/55387-quanto-list-x--new-arraylist-e-melhor-do-que-arraylist-x--new-arraylist

só mais 2 observações, que não consigo não comentar:

1 - você criou 4 pacotes, não 3.
2 - é business, não bussiness.[/quote]

Acho que vc está bem equivocado.
Model, como o próprio nome sugere, é seu modelo. Onde ficam suas regras de negócio. E em nenhum momento devem ter regras de negócio num DAO.
Esse Business é um nome mais ‘pomposo’ para o model.
E cara, só use interface se isso for realmente necessário. Vale a mesma coisa para patterns. Se vc está procurando lugar para inserí-los, então pq alguma coisa está bem errada.

#4

[quote=j0nny]Acho que vc está bem equivocado.
Model, como o próprio nome sugere, é seu modelo. Onde ficam suas regras de negócio. E em nenhum momento devem ter regras de negócio num DAO.
Esse Business é um nome mais ‘pomposo’ para o model.
E cara, só use interface se isso for realmente necessário. Vale a mesma coisa para patterns. Se vc está procurando lugar para inserí-los, então pq alguma coisa está bem errada.[/quote]

Não sei aonde me equivoquei.

Ao meu ver é assim

Model -> é a parte de dados, simples, onde (em um projeto Java EE) ficam as entidades e os DAOs.
View -> É a camada de visão, interface ao usuário
Controller -> Onde fica toda a “lógica intermediária”, onde é implementada toda a regra de negócio

Ou estou errado?

O que sei que pode acontecer é a confusão entre Controller do modelo MVC, e um nome comum aos ManagedBeans, que é QualquerCoisaController, porém os dois não são a mesma coisa. Sequer estão na mesma “fatia” do modelo MVC.

#5

[quote=digaoneves][quote=j0nny]Acho que vc está bem equivocado.
Model, como o próprio nome sugere, é seu modelo. Onde ficam suas regras de negócio. E em nenhum momento devem ter regras de negócio num DAO.
Esse Business é um nome mais ‘pomposo’ para o model.
E cara, só use interface se isso for realmente necessário. Vale a mesma coisa para patterns. Se vc está procurando lugar para inserí-los, então pq alguma coisa está bem errada.[/quote]

Não sei aonde me equivoquei.

Ao meu ver é assim

Model -> é a parte de dados, simples, onde (em um projeto Java EE) ficam as entidades e os DAOs.
View -> É a camada de visão, interface ao usuário
Controller -> Onde fica toda a “lógica intermediária”, onde é implementada toda a regra de negócio

Ou estou errado?

O que sei que pode acontecer é a confusão entre Controller do modelo MVC, e um nome comum aos ManagedBeans, que é QualquerCoisaController, porém os dois não são a mesma coisa. Sequer estão na mesma “fatia” do modelo MVC.[/quote]

DAO’s não cuidam de regras de negócio, portando não são modelos. Se o seu DAO cuida de regras de negócio, então é melhor rever sua implementação.
DAO’s fazem parte de infra, ou seja, apenas uma abstração de como seus dados serão persistidos/recuperados.

Resumindo:
Model: sua entidade, que tem suas regras de negócio tbm. Cuidado com modelos anêmicos, estamos trabalhando com OO, e não estruturação de dados.
Controller: Recebe requisições da view e delega para a camada de domínio. Controller NÃO implementa regra de negócio.
Infra: DAO, Email, etc.
View: HTML, GWT, Swing, etc.
Service/Business/Whaterer: Cuida de regras de negócio quando há mais de uma entidade envolvida.

#6

Em momento nenhum eu disse que o DAO implementa regra de negócio, veja:[quote=digaoneves]eu acho que os DAOs pertencem a camada de model, as suas classes de serviço (que implementam regras de negócio) é que ficam com o business. [/quote]
Percebeu a vírgula aí?

Agora pega esse monte de divisões que você fez e coloca no MVC, quem fica no M, no V, e no C ?

Na minha opinião você confundiu a classe Controller, com o Controller do modelo MVC, como eu disse acima.

#7

Percebeu a vírgula aí?

Agora pega esse monte de divisões que você fez e coloca no MVC, quem fica no M, no V, e no C ?

Na minha opinião você confundiu a classe Controller, com o Controller do modelo MVC, como eu disse acima.[/quote]

Model pra vc é o que?

M -> Model (entidade, bean, seilá o nome), Service/Business/Whatever. Sua REGRA DE NEGÓCIO.
V -> HTML, Swing, interface do usuário.
C -> Controller, quem recebe as ações da view e repassa pro modelo.

#8

Pra mim o Model era a parte que lidava só com dados, sem regra nenhuma de negócio aplicada (Entidades e DAOs, basicamente).
pra mim regras de negócio eram a parte do Control, e o ManagedBean (no caso) estava ligado à View.

#9

Eu acho que em um modelo simplista como o MVC suas regras de negócios ficariam no model sim. Em ambiente distribuído eu não utilizo MVC e sim multi-camadas.

#10

[quote=digaoneves]Pra mim o Model era a parte que lidava só com dados, sem regra nenhuma de negócio aplicada (Entidades e DAOs, basicamente).
pra mim regras de negócio eram a parte do Control, e o ManagedBean (no caso) estava ligado à View.

[/quote]

Saia um pouco do JSF para entender melhor.

Alguns links para vc ler:
http://www.arquiteturajava.com.br/livro/cuidado-com-o-modelo-anemico.pdf
http://martinfowler.com/bliki/AnemicDomainModel.html
http://pt.wikipedia.org/wiki/MVC

#11

Model são as classes de negócio. Quando o MVC foi criado, model referia-se ao “modelo de dados”.

Portanto, não existe uma regra clara para dizer se as classes que dão suporte as classes de negócio são também parte do model. Por isso, não adianta perder tempo discutindo. Há quem argumente que se o model é um “modelo de dados”, então o banco de dados é parte desse modelo, assim como as classes para interfacear com ele.

O fato é que, DAOs certamente não são parte do controller e nem da view. E, se não são parte do model, estão abaixo dele, em algo que não é descrito pelo MVC clássico.

Vale lembrar que persistência é uma das qualidades dos objetos, assim como é a identidade, os atributos e os métodos. O problema é que as linguagens implementam isso de maneira imperfeita, apenas levando em conta a memória volátil. Criamos DAOs apenas porque precisamos de mecanismos de persistência auxiliares para suprir essa deficiência de implementação das linguagens. Não é incomum ver frameworks ORM que criam em objetos métodos como save(), simulando o fato do objeto ter persistência própria.

Isso é parte do model? Eu também prefiro usar a terminologia do J0nny e dizer que não. Dizer que são classes de serviço auxiliares, e que não são descritas pelo MVC puro. Os dados, portanto, só seriam válidos em sua forma de objeto, não na forma de registros no banco. Mas entendo quem possa citar que esse serviço é apenas um submódulo do model.

#12

Uma longa discussão sobre isso:

Ah, e sim, regras de negócio estão no modelo, não no controle.

O controle é a parte responsável por comunicar o model com a view. Por isso, em programas desktop, ele é praticamente inexistente.

#13

[quote=ViniGodoy]Model são as classes de negócio. Quando o MVC foi criado, model referia-se ao “modelo de dados”.

Portanto, não existe uma regra clara para dizer se as classes que dão suporte as classes de negócio são também parte do model. Por isso, não adianta perder tempo discutindo. Há quem argumente que se o model é um “modelo de dados”, então o banco de dados é parte desse modelo, assim como as classes para interfacear com ele.

O fato é que, DAOs certamente não são parte do controller e nem da view. E, se não são parte do model, estão abaixo dele, em algo que não é descrito pelo MVC clássico.

Vale lembrar que persistência é uma das qualidades dos objetos, assim como é a identidade, os atributos e os métodos. O problema é que as linguagens implementam isso de maneira imperfeita, apenas levando em conta a memória volátil. Criamos DAOs apenas porque precisamos de mecanismos de persistência auxiliares para suprir essa deficiência de implementação das linguagens. Não é incomum ver frameworks ORM que criam em objetos métodos como save(), simulando o fato do objeto ter persistência própria.

Isso é parte do model? Eu também prefiro usar a terminologia do J0nny e dizer que não. Dizer que são classes de serviço auxiliares, e que não são descritas pelo MVC puro. Os dados, portanto, só seriam válidos em sua forma de objeto, não na forma de registros no banco. Mas entendo quem possa citar que esse serviço é apenas um submódulo do model.[/quote]

Fora que, num modelo MVC, não necessariamente teremos persistência de dados.
No caso do Rails, o método save do próprio objeto apenas informa que seus dados serão persistidos. Portando é de responsabilidade de alguém outro saber como fazer isso.
PS: Acho que no Rails os Adapters fazem esse trabalho de persistência, o método save do modelo apenas ‘delega’ à ele.

#14

Model - classes que recuperam e persistem algum tipo de objeto, classes que definem algum tipo de dado com métodos gets e sets. Coloque aqui os beans e os DAOs
View - classes responsáveis pela interface com o usuário
Controller - suas regras de negócio

#15

[quote=henriquecosta]Model - classes que recuperam e persistem algum tipo de objeto, classes que definem algum tipo de dado com métodos gets e sets. Coloque aqui os beans e os DAOs
View - classes responsáveis pela interface com o usuário
Controller - suas regras de negócio[/quote]

Vc realmente leu os links que coloquei anteriormente nessa thread?

#16

Uma coisa é fato, o controller não contém as regras de negócio.

Ele pode conter validações, baseadas nessas regras (assim como a view também tem). Em desktop, até isso perde o sentido, pois o mecanismo impede que um usuário burle a view, como ocorre na web. Por isso, frameworks desktop geralmente usam uma versão simplificada do MVC.

Mas a responsabilidade pelas regras, em última instância, é do model.

O model deve representar os objetos sendo desenhados, em sua completude. Deveria ser possível criar uma nova aplicação, com controllers e interface diferentes, apenas baseado no model, sem ferir regras de negócio.

[quote]Fora que, num modelo MVC, não necessariamente teremos persistência de dados.
No caso do Rails, o método save do próprio objeto apenas informa que seus dados serão persistidos. Portando é de responsabilidade de alguém outro saber como fazer isso.
PS: Acho que no Rails os Adapters fazem esse trabalho de persistência, o método save do modelo apenas ‘delega’ à ele.[/quote]

Pois é, aí entra novamente a discussão semântica. Há quem acredite que isso deva estar abaixo do model, e há quem acredite que isso é um sub-módulo do model. Agora, o importante é saber que isso não é nem view, nem controller. E que, o modelo MVC não define se persistência é ou não um atributo do model (portanto, essa é uma zona cinza que sempre gerará discussão).

Eu, particularmente, concordo com você. Até porque, tipicamente, podemos ter mais de um mecanismo de persistência para o mesmo tipo de classe. Fica mais fácil pensar conceitualmente no model como as classes que estão na memória.

#17

Acabei de ler, bacana! Nunca gostei mesmo deste padrão getters and setters, realmente na maioria das classes eles não eram nada úteis, obrigado pelos links!

#18

é, o henriquecosta mostrou que eu não fui o único que aprendeu errado, rs.

Parte culpa de um ex-gerente meu que ensinou, mas 99% culpa minha por não ter ido atrás e me informar mais.
Realmente links muito bons, provavelmente vou programar diferente daqui em diante, rs.

Realmente eu estava equivocado.

Obrigado pelos eslcarecimentos :slight_smile:

#19

Essa discussão cresceu, de fato o que entendi de MVC está todo errado.

no VIEW ao menos acertei, onde estão as minha telas.

Em Control coloquei as classes que recebem as requisições da view, coloquei as regras de negócio
lá tb.

Na Business, que no caso não existe de acordo com vcs no MVC, coloquei os DAOs que fazem a persistência/ busca dos objetos

Na Model coloquei as classes mapeadas das tabelas do banco como classe Pessoa.

Percebo que está tudo errado, de acordo com vcs, como eu deveria organizar isso? Se devo tirar as regras de negócio de Controller, onde deveriam ficar?

Percebo que meu conceito de MVC está todo errado, que m…

#20

[quote=Shatemui]Essa discussão cresceu, de fato o que entendi de MVC está todo errado.

no VIEW ao menos acertei, onde estão as minha telas.

Em Control coloquei as classes que recebem as requisições da view, coloquei as regras de negócio
lá tb.

Na Business, que no caso não existe de acordo com vcs no MVC, coloquei os DAOs que fazem a persistência/ busca dos objetos

Na Model coloquei as classes mapeadas das tabelas do banco como classe Pessoa.

Percebo que está tudo errado, de acordo com vcs, como eu deveria organizar isso? Se devo tirar as regras de negócio de Controller, onde deveriam ficar?

Percebo que meu conceito de MVC está todo errado, que m…[/quote]

Como falei, regras de negócio da entidade, devem ficar na entidade. Evite objetos anêmicos.
Regras de negócio que envolvem mais de uma entidade, vc pode criar classes Service, Business, como preferir. Lembrando que mesmo essas classes ficam na camada do Model (modelo/regras de negócio).