|
Fala Pessoal! Tudo bom? Nesse episódio do Herocast vamos conversar sobre as diferenças entre Domain Model e View Model e aprender a utilizar o AutoMapper para mapeamento automatico de objetos.
Aconteceu nesse último final de semana um dos eventos mais importantes do ano, o DNAD 2011. Esse evento conseguiu reunir no centro de São Paulo, participantes do Grupo .Net Architects de vários estados, possibilitando troca de conhecimento e muito networking dessa galera que só se conhecia por e-mail ou pelo Twitter. Primeiramente, gostaria de agradecer todos os feedbacks positivos com relação ao conteúdo que tenho publicado nesse blog. Saber que o que disponibilizo aqui ajuda tanta gente é uma ótima motivação para continuar o trabalho. Também fiquei muito feliz pela receptividade da minha Lightning Talk sobre Scrum e das discussões no Open Space.
Após a palestra na qual apresentei o conceito de persistência plugável, recebi alguns pedidos para construir uma demonstração da substituição do Entity Framework 4 pelo NHibernate. É importante ressaltar que esse procedimento é possível graças à junção de várias técnicas já conhecidas, ou seja, não estamos criando nada, apenas montando uma nova receita com ingredientes já conhecidos. Outro ponto que gostaria de ressaltar é que os conceitos aqui apresentados podem (e devem) ser aplicados em vários aspectos de um projeto, não só na camada de persistência, mas em qualquer camada que dependa de uma certa tecnologia e que precise passar a trabalhar de forma independente para que o software seja preservado..
Não somos capazes de prever o futuro, mas analisando os erros cometidos no passado, podemos determinar os efeitos colaterais que uma decisão tomada no início de um projeto terá no longo prazo. Quando iniciamos um projeto de software, vários aspectos precisam ser resolvidos: As tecnologias envolvidas, o processo que será utilizado, como o projeto será organizado, etc. Uma decisão errada em qualquer um desses aspectos pode causar danos irreversíveis no projeto e reduzir sua vida útil consideravelmente. Muitas vezes, decisões “simples” de design/arquitetura voltam para nos assombrar quando o sistema precisa ser adaptado para uma nova situação que não havia sido pensada originalmente (Já viram essa história?).
Olá Pessoal! Esse post representa minha opinião sobre uma coisa que acredito ser um dos principais problemas do nosso mercado: A dependência de tecnologias. Não quero definir a forma certa ou errada de desenvolver software (e nem poderia), mas através da apresentação de algumas idéias, espero causar algumas reflexões sobre esse tema. Há pouco tempo participei do MSDev-ES Arena : EF4 X NHibernate. O evento consistia em apresentar os dois ORMs, e minha missão era apresentar o Entity Framework 4. O evento foi ótimo. Só recebemos feedbacks positivos. A questão é que quem vai a um evento chamado Arena espera ver os dois palestrantes se digladiando, o que não aconteceu. Definir qual ORM (ou qualquer tecnologia) é melhor é uma das piores coisas que um desenvolvedor pode fazer. Sabe por quê? Por que depende de várias coisas, inclusive a pessoa que está respondendo essa pergunta infeliz. Não quero que ninguém diga: “O @denisferrari disse que o ORM X era o melhor e ele não funcionou no meu projeto!”. Não ganho nada da Microsoft ou do Ayende para defender um ORM ou outro. O que posso fazer é apresentar as características de cada um e analisar caso a caso qual tecnologia irá ajudar mais o Projeto em questão, independente da minha opinião particular ou da visão do mercado de qual é a melhor tecnologia de todas. |
|
||||||
