Delegate Chain Invocation

Callback functions são blocos de código executável que são passados como parâmetro para outro código, que fica responsável por invocá-los quando apropriado.

O modo como callback functions são suportados em cada linguagem de programação é diferente, mas são frequentemente implementados como subrotinas, expressões lambdas ou ponteiros de função.

O tratamento das linguagens não-gerenciadas sobre os callback functions é limitada a apenas um endereço de memória. Este endereço de memória não contém nenhuma informação adicional sobre o tipo de retorno, o número de parâmetros ou os tipos de dados dos parâmetros.

Saiba mais

About these ads

Gerando registros de log automáticos com o Entity Framework

Uma tarefa bastante recorrente durante o desenvolvimento de sistemas é a criação de rotinas de log. E o Entity Framework facilita a nossa vida quando temos de fazer isso.

Com o Entity Framework podemos criar uma customização que encapsule os comandos que serão enviados para o banco de dados e então adicionar uma lógica que gere os registros de log necessários para cada operação.

log de dados

Saiba mais

Construindo camadas de acesso a dados – Parte V – Unity of Work

O padrão Unit of Work mantém um rastreamento sobre todas as alterações que possam alterar sua fonte de dados durante uma transação. Assim, quando todas as alterações já tiverem sido executadas o padrão fica responsável por persistir todas na fonte de dados.

Geralmente, não somos responsáveis por implementar este padrão, acabamos por consumi-lo em ferramentas de persistência, como: Entity Framework, NHibernate e LINQ to SQL.

Saiba mais

Visual Studio Summit 2013: Patterns para criação de camadas de acesso a dados

Olá!

No último sábado (25/05/2013) tive a honra de participar do Visual Studio Summit 2013.

Participei da edição de 2012 com o tema “Principais novidades do Entity Framework 5″ (http://ferhenriquef.com/2012/09/24/visual-studio-summit-2012-principais-novidades-do-entity-framework-5-0/).

Este ano apresentei um conteúdo mais próximo aos tópicos de arquitetura e modelagem de software, falei sobre o tema “Patterns para criação de camadas de acesso a dados”.

Saiba mais

Construindo camadas de acesso a dados – Parte IV – Padrão “Find or Create”

Continuando a série de posts sobre camadas de acesso a dados (se vc não sabe do que estou falando clique aqui: Camadas de Acesso a Dados). Existe um padrão que comumente utilizamos e que não fazemos ideia de que este realmente é um padrão documentado e utilizado por muitos, este é o padrão “Find or Create”.

Este padrão consiste da característica de: buscar um determinado dado na fonte de dados e, se o mesmo não for encontrado, então fazer a sua inclusão. Pode parecer simples, mas é um recurso bastante comum que utilizamos no nosso dia.

Saiba mais

Construindo camadas de acesso a dados – Parte II – Identity Field

Dentro dos diferentes patterns de criação de camadas de acesso dados alguns deles não estão diretamente associados à construção de nossos repositórios, mas estão associados com a adequação da estrutura de nossas entidades a um determinado objetivo.

Este post é sobre um pattern chamado Identity Field.

O padrão Identity Field instrui a utilização de uma propriedade que funcione como chave de identificação de cada entidade das demais, independente do seu tipo de dados, tabela na qual estão salvos ou estrutura.

O objetvo desta chave de identificação é basicamente funcionar como identificador global, que ao contrário dos valores de campos que são chaves primárias (que geralmente são baseados em tipos inteiros, auto-incrementais e que podem se repetir em outras tabelas), agregue uma identificação única daquela tupla no banco de dados e no sistema.

Saiba mais

Construindo camadas de acesso a dados

A principal motivação para o uso de uma camada de acesso a dados (data access layer, DAL) em nossa aplicação é manter os códigos (e as tecnologias) de acesso a dados encapsulados em uma camada que fique responsável por comunicar-se com a fonte de dados, persistindo e recuperando dados de nossas entidades.

Uma camada de acesso a dados deve fornecer recursos para criação, leitura, atualização e exclusão de dados, além de controles de transação, segurança, mapeamento, concorrência, e outros. A sua criação favorece o uso de uma administração centralizada que separa o comportamento da camada de negócios das lógicas de acesso a fontes de dados e serviços.

data-net

Saiba mais

Um modelo arquitetural…

Nos últimos tempos tenho recebido algumas perguntas de como modelo meus projetos, quais design patterns utilizo e como divido minha aplicação em camadas. Estas perguntas possuem apenas uma resposta: depende do caso.

Cada aplicação merece um modelo arquitetural diferente do outro. Cada aplicação exige diferentes design patterns. Cada aplicação funciona de um jeito. Nenhuma aplicação é igual a outra, assim como os dedos das mãos não são iguais.

Mas, como esta pergunta não possui uma resposta certa ou errada, gostaria de demonstrar um modelo arquitetural que me agrada bastante. Este modelo mescla alguns design patterns e alguns princípios de projetos orientados a objetos. A arquitetura da aplicação é a demonstrada abaixo.

architecture

Saiba mais

Livro – 97 Coisas que todo arquiteto de software deve saber

Nessas últimas semanas comecei a ler o livro “97 Things Every Software Architect Should Know” (“97 Coisas que todo arquiteto de software deve saber”). Achei interessante o título do livro, pois parecia ser o resumo de diversas dicas sobre comportamento, arquitetura, compromisso e análise de sistemas… E realmente este é o conteúdo do livro…

A obra reúne pequenos textos de diversos arquitetos de software de grande expressão no cenário de tecnologia mundial. Alguns dos profissionais que colaboraram com o conteúdo desta obra trabalham em empresas como: Google, ThoughtWorks, Oracle, InfoQ, Blue River Systems Group, Software Engineering Professionals Inc, entre outros.

O livro é bastante interessante para quem procura um resumo de experiências e lições aprendidas. Não necessariamente precisa-se ser arquiteto de software para ler esse conteúdo (mesmo porque eu não sou arquiteto de software =] ), o conteúdo não é voltado para tecnologia, e sim para a troca de experiências.

Seguem algumas dicas que achei interessantes, existem muitas outras, mas gostaria de inicialmente dar destaque a estas:

- Não coloque seus objetivos técnicos a frente dos requisitos do sistema: não utilize uma tecnologia sem que ela seja necessária. Não deixe que suas tendências tecnológicas direcionem os requisitos do software.

- A arquitetura da aplicação determina sua performance: Esta parece ser uma característica óbvia, mas para muitos não é. Muitas empresas investem no tunning de servidores como solução de ganho de performance, mas performance não é apenas isso! A performance esta diretamente atrelada no modo como seu software foi arquitetado e construído. Para obter ganhos de performance, antes de mais nada, reveja sua arquitetura e procure por pontos a serem melhorados.

- Entenda a necessidade dos requisitos: Procure entender a real necessidade pela qual os requisitos são necessários. Nem sempre o requisito desejado pelo cliente será aquele que melhor atenderá a sua necessidade. Questione, pergunte, julgue as escolhas dos usuários e procure entender sua real necessidade.

- Tudo um dia irá falhar: Hardware é falível, então adicionamos redundância. Software é falível, nós adicionamos monitoramento para nos contar quando a aplicação falha, mas este monitoramento é um software, e também é falível. Seres humanos cometem erros, por isso automatizamos processos e ações. Redes são feitas de hardware e software, redes são falíveis. Todo mecanismo que utilizamos para mitigar um tipo de erro adiciona novos modos de falhas. Então o que devemos fazer, se existe a certeza de erro em nossos sistemas? Devemos aceitar que falhas são inevitáveis, e assim construir em nossos sistemas reações para alguns tipos específicos de falhas, que controlem o erro e protejam o restante do sistema.

- Patologia de padrões: Design patterns são uma das mais valiosas ferramentas disponíveis na arquitetura de software. O uso de padrões favorece a criação de soluções fáceis de compartilhar e entender. Design patterns tornam-se um problema quando nós tentamos utilizá-los em todo problema que encaramos. Não podemos deixar que nossa admiração por design patterns torne os problemas de nosso projeto mais complicados do que o necessário. Design patterns não são mágicos, e não necessariamente qualificam sua solução como ótima.

- Se existe apenas uma solução, então peça uma segunda opinião: A arquitetura de software objetiva encontrar a melhor solução para um dado problema, é muito difícil conseguir cobrir todos os requisitos e restrições com a primeira solução que vem a mente. Se você possui apenas uma solução em mente, e não possui experiência sobre o domínio do problema, então é preciso pedir ajuda a alguém mais experiente.

 

Por
Fernando Henrique Inocêncio Borba Ferreira.

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 64 outros seguidores