Ano passado 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 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 o ADO.Net 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 ai 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 algo 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 (http://pt.wikipedia.org/wiki/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!!
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 leia os artigos MVC e Camadas e Evitando VO's e BO's, leia também as referências e acompanhe o blog dele! :D
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 monstando a arquitetura da versão 2.0 em MVC, não vou usar nenhum framework, pelo menos por enquanto.
No próximo post 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 ou no MSDN Code Gallery, ainda não sei qual é o mais indicado, 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.
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 o ADO.Net 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 ai 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 algo 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 (http://pt.wikipedia.org/wiki/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!!
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 leia os artigos MVC e Camadas e Evitando VO's e BO's, leia também as referências e acompanhe o blog dele! :D
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 monstando a arquitetura da versão 2.0 em MVC, não vou usar nenhum framework, pelo menos por enquanto.
No próximo post 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 ou no MSDN Code Gallery, ainda não sei qual é o mais indicado, 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.
Postagens
2 comentários:
Olá Brandão!!!
Li seu post "Arquitetura MVC <> Camadas" e resolvi acrescentar meu comentário.
Conforme Martin Fowler em seu livro, o MVC é um padrão sim, podendo ser de duas espécies:
- Page Controller : para o caso de uma página ASPX ter um codebehind;
- Front Controller : onde um controller assume qual página ASPX utilizar para apresentar o conteúdo.
O framework 2.0 do ASP.NET tem o conteúdo de Page Controller, já a partir do ASP.NET MVC, que acredito que seja o framework 3.5 do ASP.NET, utiliza o conceito de Front Controller.
Ok? Um abraço e sucesso no seu desenvolvimento!!!
Gustavo Lucas
Porto Alegre, 30/01/2009.
Como eu escrevi no post, o MVC é sim um padrão... mas de arquitetura, já que ele faz uso de diversos padrões de projeto, que são os que você mencionou: Page Controller, Model, etc... São padrões aplicados no MVC.
Postar um comentário