Uma pergunta totalmente iniciante…
No MVC o banco de dados faz parte do Model tbm?
Seus valores são apenas modificados pelo Controller?
O model seria todo o seu POJO.
Já o control vai ser aonde vai ser implementada toda a
sua regra de negocio e sua view e todo a interface gráfica,
que o usuário vai interagir.
Espero ter ajudado!
Na verdade vc vai criar uma classe que vai manipular os dados no banco. Lá vai ter os métodos para inserir, buscar, alterar e excluir. o Controller vc vai validar algumas coisas. Você vai trabalhar com as regras de negócio.
Exemplo Simples:
M = DAO, EntityBeans
V = JSP, HTML
C = Action, ManagedBean
O Banco pode-se dizer que sim e não. 0.o Pq?
Sim porque está “relacionado” ao Model dependendo da visão.
Não por estar no contexto ‘Físico’.
[quote=Michel M]O model seria todo o seu POJO.
Já o control vai ser aonde vai ser implementada toda a
sua regra de negocio e sua view e todo a interface gráfica,
que o usuário vai interagir.
Espero ter ajudado![/quote]
As regras de negócio ficam no modelo… O controlador é quem tem a “inteligência” de interpretar os estímulos recebidos pela visão e atualiza o modelo…
[quote=Fyowti]Uma pergunta totalmente iniciante…
No MVC o banco de dados faz parte do Model tbm?
Seus valores são apenas modificados pelo Controller?[/quote]
Negão, recomendo a leitura desse artigo do Phillip Calçado; é bem esclarecedor… http://www.fragmental.com.br/wiki/index.php?title=MVC_e_Camadas
Acho que to começando a entender. Obrigado!
[quote=bob_sponja][quote=Michel M]O model seria todo o seu POJO.
Já o control vai ser aonde vai ser implementada toda a
sua regra de negocio e sua view e todo a interface gráfica,
que o usuário vai interagir.
Espero ter ajudado![/quote]
As regras de negócio ficam no modelo… O controlador é quem tem a “inteligência” de interpretar os estímulos recebidos pela visão e atualiza o modelo…
[/quote]
Não a regra de negocio e implementada no control. No model fica o POJO e o DAO é aonde fica todos os metodos que se
comunição com a base de dados.
Michel, sou obrigado a concordar com o bob_sponja.
No MVC as regras de negócio ficam no model, service layer, bussiness object!
O Controller somente trabalha com estímulos de tela e regras para a tela, ela não pode conter regras de negócio.
[quote=Michel M]O model seria todo o seu POJO.
Já o control vai ser aonde vai ser implementada toda a
sua regra de negocio e sua view e todo a interface gráfica,
que o usuário vai interagir.
Espero ter ajudado![/quote]
Na verdade não. O Modelo seria o dominio da aplicação. Nela se encontra toda a lógica de negocio. O controler deve servir apenas para fazer o meio de campo entre a visualização e dominio.
Para uma aplicação web, por exemplo, o controler é quem recebe as requisições do usuário e a passa para o dominio. O controler então pode enviar uma resposta conforme o que foi feito pelo dominio. Ele interage com o dominio, mas não contém qualquer lógica de negócio.
Já o banco de dados fica uma camada abaixo do dominio a qual podemos chamar de camada de infraestrutra.
Podemos modelar nosso dominio (modelo) usandop alguns padrãoes de projeto do Martin Fowler, assim uma classe do nosso dominio é uma Domain Model. Para que nossa classe Domain Model possa acessar os dados podemos usar um Repository em conjunto com um framework Objeto Relacional como JPA. Sendo assim retiramos a responsabilidade de acesso aos dados do dominio.
Para modelos simples não é necessário usar um Repository. Podemos usar um Active Record, que uma variação do padrão Domain Model e onde a logica do acesso aos dados fica junto com a logica do objeto do dominio. Esse é um padrão muito bom de ser usado em aplicações mais simples, onde o conhecimento da equipe não é tão grande e que pode, a medida que o sistema cresce em complexidade, ser facilmente refatorado para um modelo que use Repository e Domain Model.
Sugiro a leitura dos Livros:
DOMAIN DRIVEN DESIGN ATACANDO AS COMPLEXIDADES NO CORAÇAO DO SOFTWARE
PADROES DE ARQUITETURA DE APLICAÇOES CORPORATIVAS
Nesses livros fala sobre MVC, camada de negocios, MVC, banco de dados etc.
[quote=Michel M][quote=bob_sponja][quote=Michel M]O model seria todo o seu POJO.
Já o control vai ser aonde vai ser implementada toda a
sua regra de negocio e sua view e todo a interface gráfica,
que o usuário vai interagir.
Espero ter ajudado![/quote]
As regras de negócio ficam no modelo… O controlador é quem tem a “inteligência” de interpretar os estímulos recebidos pela visão e atualiza o modelo…
[/quote]
Não a regra de negocio e implementada no control. No model fica o POJO e o DAO é aonde fica todos os metodos que se
comunição com a base de dados. [/quote]
Sugiro que de uma lida aqui:
http://blog.fragmental.com.br/2007/02/24/grandes-gordas-e-sem-sentido/
[quote=Michel M][quote=bob_sponja][quote=Michel M]O model seria todo o seu POJO.
Já o control vai ser aonde vai ser implementada toda a
sua regra de negocio e sua view e todo a interface gráfica,
que o usuário vai interagir.
Espero ter ajudado![/quote]
As regras de negócio ficam no modelo… O controlador é quem tem a “inteligência” de interpretar os estímulos recebidos pela visão e atualiza o modelo…
[/quote]
Não a regra de negocio e implementada no control. No model fica o POJO e o DAO é aonde fica todos os metodos que se
comunição com a base de dados. [/quote]
Cara, vc tá confundindo MVC com CAMADAS… O MVC diz como deve ser a interação entre componentes, e as CAMADAS diz quais são as responsabilidades de cada uma…
Sugiro também esse artigo do Sérgio Taborda, que ataca forte essa confusão entre CAMADAS e MVC: http://sergiotaborda.javabuilding.com/2009/11/mvc-e-camadas/
[quote=x@ndy][quote=Michel M][quote=bob_sponja][quote=Michel M]O model seria todo o seu POJO.
Já o control vai ser aonde vai ser implementada toda a
sua regra de negocio e sua view e todo a interface gráfica,
que o usuário vai interagir.
Espero ter ajudado![/quote]
As regras de negócio ficam no modelo… O controlador é quem tem a “inteligência” de interpretar os estímulos recebidos pela visão e atualiza o modelo…
[/quote]
Não a regra de negocio e implementada no control. No model fica o POJO e o DAO é aonde fica todos os metodos que se
comunição com a base de dados. [/quote]
Sugiro que de uma lida aqui:
http://blog.fragmental.com.br/2007/02/24/grandes-gordas-e-sem-sentido/[/quote]
Afinal, onde fica as regras de negócio, no Model ou no Control? Alguém pode dar um exemplo pratico para web?
[]'s
[quote=luizinfo]
Afinal, onde fica as regras de negócio, no Model ou no Control? Alguém pode dar um exemplo pratico para web?
[]'s[/quote]
No modelo!
Como antes sugiro a leitura do link abaixo.
http://blog.fragmental.com.br/2007/02/24/grandes-gordas-e-sem-sentido/[/quote]
Os POJOS contém as regras de negócio. O problema é que o pessoal fala sem saber. Para ele POJO é sinônimo de objeto Burro os antigos VOs, o pessoal então considera que os objetos persistentes devem conter somente os dados então acha que o modelo é somente esse monte de objetos persistentes que não tem lógica nenhuma o que é muito similar a uma struct do C um record do Pascal. Como tem que colocar a lógica de negócios em algum lugar eles colocam no controle que devia apenas fazer o meio de campo entre a View e Modelo. Ai a orientação a objetos foi pro saco e começa a ter um monte de código repetido por todo o lugar.
Exemplos nessa área não se em meia duzia de linhas então sugiro a leitura do Livro Padrões de Arquitetura Corporativa do Martin Fowler que é uma referência do assunto!
PS: Também indico, ótimo artigo
Este assunto causa dúvidas mesmo, pois a palavra Controlador é usada em vários contextos diferentes. Cito abaixo um trecho do livro do Martin Fowler que fala sobre isso:
Então entendo que a regra de negócio realmente não fica no controlador, pelo menos não no controlador MVC.
No livro Utilizando UML e Padrões, Craig Larman fala sobre um outro tipo de controlador: o controlador GRASP. Os padrões denominados GRASP (General Responsibility Assignment Software Patterns) são padrões e ao mesmo tempo princípios para atribuir responsabilidades.
Abaixo a definição do padrão Controlador no livro:
E abaixo a explicação do livro sobre a diferença entre o controlador GRASP e o controlador MVC:
Nesse mesmo livro (pág. 322 da 3a. edição), Craig Larman diz que no Processo Unificado e no método Objectory de Jacobson há três tipos de objetos:
- objetos de fronteira - abstrações das interfaces (por exemplo, classes Swing).
- objetos de entidade - objetos de domínio (negócio ou modelo) independentes da aplicação e geralmente persistentes.
- objetos de controle - são tratadores de caso de uso.
Aí mais um contexto para controlador, ou, neste caso, objeto de controle.
Link para o livro do Martin Fowler:
http://books.google.com.br/books?id=vpHqYZcmeKsC&printsec=frontcover&dq=martin+fowler+padr%C3%A3o+de+arquitetura+de+aplica%C3%A7%C3%B5es+corporativas+mvc&hl=pt-BR&sa=X&ei=EN_DT8CnL4P26AGBoITZCg&ved=0CEEQ6AEwAA#v=onepage&q&f=false
Link para o livro do Craig Larman:
http://books.google.com.br/books?id=ZHtcynS03DIC&printsec=frontcover&hl=pt-BR&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false
[quote=Fyowti]Uma pergunta totalmente iniciante…
No MVC o banco de dados faz parte do Model tbm?
Seus valores são apenas modificados pelo Controller?[/quote]
Lá vamos nós de novo …
Como alguém já citou aqui, eu já discuti isso no meu blog. MVC não é camadas. O que vc está perguntando é sobre camadas. (não é bem, mas já lá chego)
Então vamos esquecer esse papo de MVC.
Vamos pensar Separação de Responsabilidades. Eu sei que tem um objeto ou conjunto de objetos que detêm os “dados”, outro que detem “a regra/ o processo” e o outro que detêm “a interação”. Agora eu quero separar o meu código de forma a separa bem estas responsabilidades.
Dois cenários:
Eu estou considerando o sistema com um todo. Eu vejo nele estes três “papeis”.
Qual é o padrão que eu devo seguir ?
O padrão ECB (Entity-Control-Boundary)
O MVC é uma forma de desenhar componentes dentro de uma camada. Não uma forma de organizar o sistema.
Este tipo de componentes que se utilizam do MVC normalmente tem algum fator do padrão Observer que é necessário considerar ( o que não acontece no ECB) e é mais apto para a camada de apresentação.
O SGBD representa uma tecnologia de acesso a recursos da camada de Recursos, e os dados em si (as tabelas) representam as entidades dessa mesma camada.
O valores são modificados pelo controlador da camada acima (Integração) pois a camada de recursos não possui controladores.
Acho que o texto que citei acima resume bem a diferença e responde à sua pergunta
Sergio,
Li o artigo “Arquitetura ECB e o Mistério do MVC em Camadas” no seu site e achei muito interessante.
Como eu disse na mensagem anterior, este assunto causa dúvidas. O Martin Fowler diz que a palavra “Controlador” é utilizada em vários contextos, o que causa confusão. Mas espero que estes tópicos deixem tudo mais claro para todos.
Estou entendendo que os objetos de Fronteira, Entidade e Controle do método Objectory que citei constituem o padrão ECB (Entity-Control-Boundary) de que você fala no artigo.
Fiquei com duas dúvidas:
-
No livro do Craig Larman ele fala sobre o padrão Controlador GRASP, equivalente a algumas variações do padrão controlador fachada (façade controller) ou a um controlador de caso de uso ou sessão. O controlador GRASP fica na camada de domínio. No artigo você diz que a camada de domínio pode conter objetos de controle, entidade e fronteira. O controlador GRASP é equivalente ao objeto de controle dentro da camada de domínio?
-
Estou anexando a apostila do Phillip Calçado, de Spring Framework, onde ele tem um exemplo de implementação de camada de domínio no capítulo 7.
Na apostila o Phillip Calçado ele fala sobre alguns padrões que podem ser observados ao modelar a camada de domínio. Entre eles o padrão Service. Cito trecho da apostila.
No seu artigo você diz o seguinte:
A minha dúvida é a seguinte: quando você implenta os objetos de controle na camada de domínio utilizando Services, eles devem possuir regra de negócio? O Phillip Calçado diz que é importante que Services não implementem as regras de negócio, você concorda? Se a regra de negócio não fica nos Services, existe outro tipo de objeto de controle na camada de domínio que implemente regras de negócio?
[quote=al.barbosa]Sergio,
Li o artigo “Arquitetura ECB e o Mistério do MVC em Camadas” no seu site e achei muito interessante.
Como eu disse na mensagem anterior, este assunto causa dúvidas. O Martin Fowler diz que a palavra “Controlador” é utilizada em vários contextos, o que causa confusão. Mas espero que estes tópicos deixem tudo mais claro para todos.
Estou entendendo que os objetos de Fronteira, Entidade e Controle do método Objectory que citei constituem o padrão ECB (Entity-Control-Boundary) de que você fala no artigo.
Fiquei com duas dúvidas:
- No livro do Craig Larman ele fala sobre o padrão Controlador GRASP, equivalente a algumas variações do padrão controlador fachada (façade controller) ou a um controlador de caso de uso ou sessão. O controlador GRASP fica na camada de domínio. No artigo você diz que a camada de domínio pode conter objetos de controle, entidade e fronteira. O controlador GRASP é equivalente ao objeto de controle dentro da camada de domínio?
[/quote]
Eu não tenho um bom conhecimento sobre GRASP, daquilo que eu tendendo o GRASP sugere padrões de responsabilidade e não padrões de design.
NO sentido GRAPS o controler é qualquer componente que tenha a responsabilidade de “controlar” a resposta. Isto pode ser o controler do MVC, o controlador do ECB , mas também pode ser um service façade (como diz na wikipedia). O GRASP não é bom para criar arquitetura no sentido usual porque é uma filosofia ortogonal que visa resolver outros problemas. Eu removeria o GRASP da equação ao discutir camadas/MVC/ECB porque não trás nada de novo e causa confusão que os padrões GRASP não são design patterns ( são na realidade os meta padrões de onde os design patterns nascem)
Conceptualmente eu concordo com essa visão, mas é preciso entender o que está sendo dito. Aliás o meu próximo blog seria exatamente sobre isto.
A diferença está nos nomes. Para mim o padrão Service é bem lato e simples. Então eu vejo o uso do mesmo padrão em cenários diferentes. Principalmente 3. Usando a mesma terminologia que o artigo : como façade , como componente e como DAO. Para mim o DAO não é um Repositorio é tão a implementação de Service como Money é implementação de Value Object. são padrões derivados que de tão importantes ou comuns ganham um nome especial.
Portanto, resumindo, estamos dizendo a mesma coisa. Quando a camada A chama a camada B o ponto de entrada em B sempre é um Service. Deverá ser sempre um Façade a bem do design. Este façade chama então outros services ( que podem ser façade ou não) e objetos Repository. Estes outros services “internos” à camada é que implementam as regras de negócio.
Ha uma diferença subtil entre pensar em “service de negocio” e “component de negocio”. O Service é um padrão que obriga a definição de um contrato em separado da implementação. Um componente, em geral, não precisa disto. Pode ser que dentro da camada de dominio realmente as regras não precisem de services ( estou pensando em straegy, specification e validator) e então realmente podemos considerar que ha um diferença prática na implementação e no conceito de componente vs service. Mas o conceito de um conjunto de objetos que forma a parte “publica” e são apenas façadas que canalizam para objetos do domínio é comum e é o que importa retirar desta conversa.
O Service Façade é um tipo especifico de Service que não contém lógica de regra, apenas orquestração de outros objetos.
O Service ( sem sufixo ou prefixo) é um padrão simples que apenas estipula que vc deve ter uma interface e várias possíveis implementações.
Um Business Component é algo mais virado ao domínio e muitos objetos podem ser Business Components, inclusive os Services, mas não apenas eles.
Se vc usa o padrão Business Component, então realmente vc está usando outra filosofia de design que não se limita a services.
Sergio,
Obrigado. Esclareceu bastante os conceitos.