Archive for the ‘Design’ Category
Fala Pessoal, tudo bom? O Herocast dessa semana aborda um tema muito bacana: A tradução de um modelo uml em código e seu respectivo mapeamento utilizando o Fluent NHibernate. O Objetivo é apresentar uma visão geral sobre os dois temas, dar algumas dicas e simplificar conceitos que parecem complicados de início. Espero que gostem!
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.  É impressionante como a repetição de uma determinada atividade faz com que nós, executores, percamos de vista a razão por trás dela. Isso é comum, mas não é bom na área de desenvolvimento, afinal, se uma tarefa é repetitiva e não exige reflexão, podemos colocar um robô no nosso lugar, que além de ser mais barato, vai errar menos. Participando de alguns grupos de discussão, percebo que muitos profissionais, em diferentes níveis de maturidade, seguem regras sem analisar o contexto em que estão inseridos. Isso é normal em profissionais inexperientes, afinal, ninguém nasce competente, mas quando falamos de profissionais com mais tempo de experiência, o argumento “Faço assim por que é o certo” pode justificar uma decisão que acarretará em prejuízos enormes para o projeto.
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.
Fala Galera! O episódio de hoje foi baseado em parte do treinamento que ministrei no último sábado para alguns alunos da UNES. Busquei simplificar alguns conceitos complicados ou que geralmente são apresentados com uma abordagem não tão prática. Usei o exemplo do segundo episódio para guiar a explicação. Nesse episódio apresentei três regras simples para um bom design orientado a objetos: Uma classe deve conter apenas uma responsabilidade, quem usa uma classe não a cria e não sabe como ela funciona. Vale a pena conferir.
Fala Galera! Chegamos ao terceiro episódio do #HeroCast. Para quem não viu os episódios anterirores, pode conferir aqui. O objetivo desse episódio é mostrar como organizar os módulos de um sistema de informação de forma que não existam dependências diretas entre eles. Na prática, criamos um canal compartilhado de comunicação onde definimos nossos contratos e usamos esse canal para conseguir que os módulos se comuniquem sem se conhecerem. Vale a pena conferir.
Fala Galera! Antes de tudo quero agradecer os feedbacks sobre o primeiro episódio do #HeroCast. Fiquei muito feliz ao ver que o vídeo ajudou muita gente a entender conceitos que muitas vezes não damos tanta importância no nosso dia-a-dia. Os assuntos tratados nesse episódio foram: Separação de tecnologia e regra de negócio, POO, Dependências nos construtores de uma classe, Testes, Stubs e Mocks, ADO.NET, OpenSMTP e alguns outros. Vale a pena conferir.
Esse vídeo é o primeiro de uma série que planejo publicar semanalmente. A idéia é mostrar a aplicação prática de conceitos que tenho falado aqui no blog e nas palestras que realizei. Como o tempo é curto, deixo a conclusão da implementação por conta de vocês. Nesse primeiro episódio construo um montador de comandos SQL (Delete, Select…). Utilizo TDD para construir o código, mas o objetivo não é ensinar TDD, e sim usá-lo como guia para apresentar alguns conceitos que julgo importante. Vejam o resultado final e comentem! Preciso do feedback de vocês para o próximo vídeo.
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?). |
|
||||||
