none
Estaria a Microsoft re-inventando o MVC ??? RRS feed

  • Discussão Geral

  • Olá a todos!

    Eu sou formado em Análise de Sistemas pela Universidade Estácio de Sá (2005), pós-graduado em Análise, Projeto e Gerencia de Sistemas também pela Universidade Estácio de Sá (2009) e tenho um MBA em Engenharia de Software pela Universidade Federal do Rio de Janeiro (UFRJ) (2010).

    Atualmente trabalho com desenvolvimento em C#, mas já trabalhei com Java. Hoje apenas C# mesmo. Estou feliz com ele. Não sou apenas desenvolvedor, sou analista de sistemas desenvolvedor. Sempre desenvolvi com MVC (desde o meu primeiro projeto profissional feito em Delphi 5).

    Nestes três cursos que fiz eu aprendi que no MVC as regras de negócio ficam no CONTROLLER. As VIEW são apenas camadas de apresentação que pode ter regras referentes apenas a tela (por exemplo definir as cores dos campos dinamicamente) e que as MODEL devem apenas manter a comunicação com o banco de dados. As regras de negócio da aplicação devem ficar no CONTROLLER. Foi assim que aprendi! Mas não é assim o Framework ASP.NET MVC 3 da Microsoft.

    Li no artigo ASP.NET MVC 3 - Parte 1 da revista .Net Magazine edição 81 que as regras de negócio ficam na MODEL e que o CONTROLLER apenas decide qual VIEW usar e que por conta disso, a camada CONTROLLER é a que possui menos código. Isso é justamente o oposto completo de tudo que aprendi em MVC! Os CONTROLLERS são as classes que possuem mais código pois são elas que mantém as regras de negócio do projeto e gerenciam o fluxo de execução da aplicação, e não a MODEL.

    Para cada tabela no meu banco de dados eu tenho uma classe MODEL, CONTROLLER e VIEW, além de uma classe VO (Value Object). Eu sempre as chamo assim: MODEL -> DAO (Data Access Object), CONTROLLER -> Control, VIEW são as páginas aspx ou as telas (WinForm ou xaml) e as VO que possuem apenas os atributos da entidade e seus construtores.

    Exemplo: Tabela Clientes -> ClienteDAO (MODEL), ClienteControl (CONTROLLER), cliente.aspx / cliente.xaml (VIEW) e Cliente (VO).

    Antes de trabalhar com C#, trabalhando com Java, todos os projetos que participei sempre foram assim (alguns não usavam VO, colocavam os atributos da entidade no MODEL), com regras de negócio nos CONTROLLER. Foi assim que aprendi e é assim que sempre trabalhei. Minha arquitetura MVC sempre foi amplamente elogiada e já em três empresas que passei, assim que fui contratado ao apresentar minha arquitetura o pessoal gostou e a adotou como forma padrão para os novos projetos da empresa.

    Pelo que sei, alguns desenvolvedores também usam regras de negócio em MODEL, na minha opnião muito provavelmente por influência da Microsoft que ao meu ver, esta alterando o MVC. Tem gente que chegou a me dizer que o MVC desde quando foi utilizado no SmallTalk já era com regras no MODEL. Nunca vi isso em lugar nenhum! E nunca tinha escutado isso antes!

    Pesquisando na internet, vejo a maioria dos artigos dizendo que as regras ficam no CONTROLLER, algus dizem que ficam no MODEL. O artigo que li da revista .Net Magazine também disse que deve ficar no MODEL. Automaticamente desconsiderei o artigo, mas continuei lendo.

    Particularmente acho errado colocar regras no MODEL. Acredito que estaríamos perdendo coesão. Quando tenho que alterar uma lógica na regra de negócio de cliente por exemplo eu vou na classe ClienteControl. Quando tenho que alterar uma lógica no acesso ao banco de dados (ou simplesmente incluir a informação de uma nova coluna da tabela) eu vou na classe ClienteDAO. São coisas diferentes!!! Não faz sentido mantê-las na mesma classe! E o principio de uma classe uma responsabilidade que eu aprendi nas aulas de Arquitetura de Software? Ter uma única classe que faz essas duas coisas seíra ao meu ver perda de coesão da classe.

    No livro Use a Cabeça! Padrões e Projetos, eles abordam o MVC, mas deixam claro que o MVC é um padrão de arquitetura e não de design (o que também aprendi e concordo nas aulas de Arquitetura de Software), mas por incrível que pareça, em alguns casos a VIEW deles fazem acesso direto ao MODEL! Como assim??? Isso é o maior crime que se pode cometer em MVC. Um cara que faz isso deve ser preso!!!

    Ai agora vem a Microsoft colocando regras de negócio no MODEL? Acho isso errado e continuarei com as regras de negócio nos CONTROLLERS. Sendo assim, não utilizarei o framework de MVC da Microsoft (que desde que ouvi falar eu já imaginava que alguma coisa a Microsoft iria inventar, ou seja, já tinha um pé atrás)

    Como sou novo em C# (apenas 5 meses), tenho poucos contatos com pessoas nesta linguagem. A maioria dos meus colegas são Java.

    Gostaria de ver o que pensam o pessoal do C#/VB e também a opnião dos moderadores. Se alguém da Microsoft escrever algo seria melhor ainda.

    Esse é o meu ponto de vista!

    Um forte abraço a todos!


    - Tiago Maia Analista de Sistemas/Desenvolvedor C#
    • Movido Ricardo Oneda quarta-feira, 16 de março de 2011 14:57 (De:.NET Development - Geral)
    quarta-feira, 16 de março de 2011 12:18

Todas as Respostas

  • Olá Tiago!

    Bom, não sei quais artigos você leu. Mas, parece que está você está se confundindo com o uso do termo MODEL. Atualmente, o termo model é utilizado de duas maneiras diferentes. Uma é a do MVC, onde o Model representa os dados que serão exibidos na tela. A outra é do DDD (Domain-Driven Design), onde o Model representa o seu modelo de domínio. Alguns chamam o Model do MVC de View Model e o Model do DDD também é chamado de Domain Model. (Espero que o texto não tenha ficado muito confuso). Seguem alguns links sobre DDD:

    http://en.wikipedia.org/wiki/Domain-driven_design

    http://domaindrivendesign.org/

    http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215 (se você não é familiarizado com DDD, sugiro fortemente que leia livro)

    Como você pode ver, o mesmo termo é (pode ser) utilizado em situações diferentes. E, a propósito, nada impede que uma classe do DOMAIN MODEL seja também seu MODEL (do MVC). Você é quem tem que pesar os prós e contras desta abordagem. Particularmente, não gosto dela.

    Sobre controllers, não costumo colocar regras de negócio neles. Em minhas aplicaçãos, eles são responsável apenas pelo fluxo e não pelas regras. As regra de negócios ficam nas entidades que crio a partir do entendimento do domínio do problema (o Domain Model)

    Views acessando o Model? Também não vejo problemas. Desde que estejamos falando do Model do MVC e não do Domain Model.

    Espero ter ajudado.


    Allan
    quarta-feira, 16 de março de 2011 18:02