Regras de negócio no modelo MVC
Enviado por Ricardo Lopes Bez Fontana (fontanaricardoΘgmail·com):
“Recentemente participei de um treinamento sobre ZendFramework em minha empresa, neste treinamento foram abordadas várias questões sobre o famework como comunicação com banco de dados, elaboração da interface gráfica, entre outras… Certo momento, no decorrer do treinamento, foi abordada a criação das regras de negócio, sendo que o instrutor informou que sua empresa armazenava tais regras no controller, depois disso iniciou-se uma longa discussão sobre o assunto. Depois deste episódio resolvi questionar aos alunos, sobre como suas empresas trabalhavam com esta arquitetura. Com exceção de dois alunos, um informou que implementa as regras no model e outro que implementa na view (por motivos de performance), todos os demais informaram que implementam as regras no controller. Com isso cheguei a duas conclusões: 1) O modelo MVC, apesar de muito difundido devido a adoção da internet como infraestrutura de serviços, nem sempre é corretamente aplicado. 2) Sempre que há uma discussão sobre desenvolvimento, quem não está amparado tecnicamente, utiliza o fato de “funcionar” como argumento, por mais que fazer errado seja mais trabalhoso. Sendo assim resolvi estudar um pouco mais o modelo e confrontar alguns dos argumentos:” [referência: blogf13.blogspot.com]
• Publicado por Augusto Campos em
2011-12-19
@brlinuxblog
Feed RSS
Ricardo (autor do post), sem a intenção de faltar o respeito, mas bem mixuruca esse post.
Falar que é errado adicionar regra no model, mas não falar quais os benefícios dessas regras estarem no model, não adianta nada. Acaba caindo no seu ponto das 10 ou 100 licensas, eu quero fazer da forma mais benéfica para o MEU software e não ficar de mimimi com padrões e regras “da cultura da ti”, certo? O mais próximo que você chegou de um possível “benefício” foi no momento em que cita testes, mas mesmo assim estes foram direcionados a criticar o fato das regras serem implementadas nas views, sem contar que o tipo de teste tbm não ficou claro.
Enfim, mais uma documentação que colabora para o bom profissional que sabe que está errado (ou certo), mas não sabe porque.
Discursão é um discurso grande.
MVC as vezes vira meio que uma “religião” ou “guerra santa”, sempre gera intermináveis discussões – algumas são bem interessantes é verdade – geralmente inconclusivas, onde os envolvidos saem achando a mesma coisa que achavam antes.
Particularmente acho MVC muito legal, sempre que possível adoto, mas as vezes em algumas situações é inaplicável. No caso específico do ZF ele mesmo quebra o padrão em alguns recursos que oferece (começando pelo Zend Form).
pra mim foi sempre claro, regra de negócio é pra ficar no model, o mvc é só pra ligar o model a view. Colocar regra de negócio no controler acaba com a razão do mvc existir e gera um acoplamento muito forte entre o framework e o sistema.
É uma pena que muitas pessoas ainda deixam de colocar negócio no modelo fazendo assim com que o modelo fique anêmico, o que inclusive é considerado um anti-pattern.
discursão????
Para min as regras de negócio sempre devem ficar na model. Não gosto da ideia delas na view ou na control.
[]‘s
Pra mim não resta dúvida de que as regras de negócio ficam no model. Não é questão de ficar mais “bonito”. Vem da função de cada camada. Função do controller é só receber “comandos” do usuário e passá-lo para o model correspondente. Em teoria é função do Model atualizar a View, mas no fim das contas a maioria dos frameworks exige que a atualização da view seja feita pelo controller.
Ou seja, as implementações em geral estão erradas. Chamem de qualquer outra coisa, menos MVC.
Na verdade o controller é quase sempre desnecessário ou tem funções bastante reduzidas. Tanto que vários frameworks hoje já utilizam o MV, sem o C.
Não digo que é errado colocar alguma regra de negócio (meu, odeio esta expressão, malditas aulas de Engenharia de Software), mas não se pode chamar isso de MVC.
Ah sim, outra coisa que os frameworks em geral pecam é em embutir no model tanto a persistência quanto coisas das regras de negócio. Fico tudo embrulhado. O ideal mesmo é criar uma camada só para abstrair a persistência (como se toda aplicação fizesse persistência…) e deixar outra para as regras de negócio. Uma boa abordagem é o DAO.