(Nota: publiquei esse post inicialmente aqui, como movi o meu blog , e recebi pedidos para comentar mais a respeito, estou revisando e postando aqui para continuar a série de posts do blog antigo)
Estou desenvolvendo um novo sistema baseado na arquitetura MVC, ou melhor, pensei que estava.
Em 2007, participei da integração de um sistema legado ASP.Net com SAP que estava sendo implantado. O sistema já estava construído e basicamente deveríamos integrá-lo ao SAP usando Web Services disponibilizados através do serviço XI da SAP. Ou seja, ao invés de continuar buscando os dados no banco de dados Oracle, iríamos agora buscar no SAP, através de Web Services.
O sistema usava a arquitetura MVC. Usava? Bom, eu tinha uma DLL onde ficavam as classes Model, outra de Controller, tinha a interface gráfica em ASP.Net, mas eram somente camadas… Opa, mas MVC não são camadas?
Esse foi o meu primeiro contato com MVC e a partir daí comecei a estudar mais sobre padrões e arquitetura, e lógico vi que era hora de me aprofundar em Orientação a Objetos… Sim isso mesmo, aprofundar.
Eu vim do VB6 (por favor, VB6 é sim uma linguagem de gente grande!), quando comecei a programar o ADO estava sendo lançado, praticamente. Logo em seguida tive contato com a arquitetura Win DNA (Windows Distributed interNet Applications Architecture), como o link diz é um nome marketeiro para tecnologias que já existiam mas foram agrupadas em uma arquitetura (COM, COM+, antigo MTS; ADO, ActiveX, ASP). Na época a minha bíblia era o livro Mary Kirtland, posteriormente li também o livro do Fábio Câmara.
E foi aí que surgiu para mim o conceito de camadas, dividir para conquistar, já que na época tínhamos o DLL Hell, era muito bom você criar pequenos componentes que sofreriam manutenção em separado, e nada melhor do que juntar esses componentes por funcionalidades! Assim os componentes usados para a interface gráfica ficavam juntos, o de acesso a dados ficavam em outro, o que diminuía a possibilidade de dar um problemão quando alguma coisa sofria manutenção, eu disse diminuía…
Daí pra frente eu só desenvolvia em camadas, camadas lógicas, pois na verdade o software ficava instalado todo na máquina cliente, ou seja, eram instaladas várias DLL’s, mas todas no mesmo lugar. Algum projeto saiu usando o COM+, aí tinhamos Tiers, componentes usados em interface gráfica ficava na máquina cliente e compoentes de negócio e banco de dados ficavam no servidor.
Mas onde entra o MVC aí? Aí é que está… Não entra!! O MVC não é sinônimo de desenvolvimento em camadas! Nem em tiers! O MVC é um padrão de arquitetura, e ele é baseado no comportamento dos objetos. Sim, comportamento!! E mais, o MVC é padrão para interface gráfica, e não para todo o sistema.
Muitos de nós, principalmente que viemos do VB6, Win DNA, …; começamos desenvolvendo em OO criando classes que tem os atributos como os RecordSets do ADO, ou seja somente dados! Mas um objeto por definição possui comportamento. Então não adianta criar uma classe de dados, como se fosse um RecordSet, uma classe de serviço como se fosse uma classe do VB6 (que sim, antes que alguém fale, não é orientado a objeto, porém chegava perto…), e ficar passeando pelas camadas, que isso é MVC. Aliás nem OO é, pois você não estará usando comportamentos dos objetos.
Não vou chover no molhado explicando isso aqui, o Phillip Calçado Shoes já escreveu um artigo muito bom sobre isso, então usando um dos princípio de OO que é a reusabilidade , para saber mais leia os artigos MVC e Camadas e Evitando VO’s e BO’s, leia também as referências e acompanhe o blog dele! 
Na edição 46 da .Net Magazine o Rodrigo Sendin escreveu um artigo sobre MVC, porém quem leu o artigo e ler os artigos do Phillip Calçado vai entender que a crítica do Rodrigo esta errada quanto ao padrão MVC.
Bom se eu não vou explicar o que é MVC, nem camadas, nem BO ou VO, então pra que este post? Como eu disse estava desenvolvendo um projeto pensando estar usando MVC, no momento na versão 1.0 ele irá sair usando BO’s, trafegando pelas camadas, etc… Mas estou montando a arquitetura da versão 2.0 em MVC, não vou usar nenhum framework, pelo menos por enquanto.
No próximo post (espero mesmo começar aqui neste novo endereço do blog em breve) vou começar uma série de artigos compartilhando minha experiência, principalmente com uso de objetos POCO, pois percebo que no Brasil o uso de DataSet’s é abusivo, logicamente para pequenos projetos é uma boa solução mas para projetos médios, ou com muitos acessos ao banco de dados o peso começa aumentar. E também vou dar um foco no acesso a dados. Vou publicar o código acho que no CodePlex (o código esta aqui, ou melhor, estará ), daí é só baixar o código para estudar ou começar outro projeto em cima. Quem quiser se unir a empreitada é só entrar em contato.
Espero que acompanhem, comentem, entrem em contato para trocarmos idéias.
