| Últimas 20 atualizações de CADU |
|
|
Atualmente quando falamos de arquitetura, vemos esforços em manter a
lógica do Domínio isolada, no caso de quem trabalha com Domain Drive Design, e
ter camadas com clara separação de responsabilidades, manter um baixo
acoplamento na hora de fazer as camadas se comunicarem, mais, também não
podemos esquecer da UI. A UI( user interface ), ou, interface com o usuário,
geralmente é o front-end com quem nosso usuário final interage e realiza suas
principais ações, como inserção de dados, pesquisas, geração de relatórios e
etc; Na hora de definir a arquitetura de um sistema, não podemos esquecer de
como faremos para organizar a comunicação desta camada, com toda a
infra-estrutura para comportar o negócio que o sistema irá gerenciar.
O que geralmente acontece, é que acaba se misturando código de UI com código
que realizam outras funções que não é da UI, como código de banco de dados e
etc. Além de causar uma grande confusão no código, em cenários como este, a
manutenção é um desafio e a evolução é uma lenda; trabalhar desta forma é
impraticável.
Existe o
que chamamos de Separated Presentation patterns, que tem por objetivo
justamente organizar a maneira de como a UI irá se comunicar com outras camadas
da aplicação e permitir que o código que executa a lógica da aplicação, seja
testável e desacoplado; deixando para a UI, apenas as responsabilidades a ela
pertinentes como manipulação de controles, validação de input de dados e
repassando para as camadas devidas os demais aspectos da aplicação.
Introduzido por Martin Fowler, este tipo de pattern, tem como objetivo,
focar no objetivo de separar o domínio da solução, das demais camadas,
inclusive da UI, fazendo com que o Domínio da solução desconheça completamente
qualquer detalhe referente à apresentação, ou seja, a camada de UI. A figura,
abaixo mostra alguns dos Separation Presentation Patterns:
Cada um dos patterns mostrados na figura anterior, pode ser aplicado em uma variedade muito grande de cenários, não importando se sua UI, é um aplicativo Windows forms, Console, WPF, silverlight ou ASP.NET. Observe a figura abaixo:
A figura acima
ilustra um cenário indesejado, em que uma aplicação web abriga aspectos que não
são de sua responsabilidade como log, acesso a dados e acesso a serviços. Veja
que em uma aplicação, como a ilustrada pela figura acima, existe uma bagunça
generalizada, por acoplar aspectos que deveriam estarem separados e focados em
realizar tarefas apenas de sua responsabilidade. A figura abaixo ilustra o
cenário ideal e que os patterns presentation, nos auxilia a alcançar:
... Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Objetos ou Estruturas de dados? A pergunta surge pelo fato de que embora hoje existam linguagens e ferramentas que dão total suporte ao desenvolvimento orientado a objetos, nem todos os desenvolvedores fazem uso de todos os recurso que a OO oferece. A Orientação a objetos nos diz que “objetos são representações de personagens do mundo real” e “objetos reúnem dados e comportamento”, mais ao contrário destas definições o que vemos é o que mostra a figura abaixo:
O que vemos na imagen acima, é o que a anos vem sendo feito em questão de modelagem de software. As classes, ao invés de serem representações de personagens do mundo real, passam a ser a representação das tabelas do banco de dados, indo totalmente contra os princípios da orientação a objetos. Pode parecer muito purismo, mais quando se trata de software temos questões como manutenção, evolução e correção de erros; uma vez utilizando abordagens como a demostrada acima, estas tarefas se tornam muito difíceis e custosas de se fazer. Objetos x Estruturas de Dados Como identificar quando temos um objeto e quando temos uma estrutura de dados? É simples como na figura mostrada anteriormente, o que temos é uma estrutura de dados que é uma classe que expõe seus atributos, onde o consumidor da classe pode livremente acessar suas propriedades e modifica-las; Já quando temos objetos, os mesmos, não permitem que seus dados sejam modificados diretamente, mais expõem métodos que efetuam tais mudanças, ou seja, quando o consumidor da classe deseja realizar alguma operação no objeto em questão, ele chama um de seus métodos para realizar tal tarefa. Observe o exemplo abaixo, de como ficaria o cenário abordado na figura anterior contemplando a orientação a objetos:
Observe o código abaixo da classe cliente:
... Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Aplicativos portáteis, não são novidade na atualidade. A facilidade de utilizar um aplicativo sem a necessidade de ter que instalá-lo, e não ter mais um software ocupando espaço em disco é fantástica; os fatos citados, fizeram grandes fabricantes como a Adobe, Corel e outros, lançarem seus famosos produtos portáteis.
No dia 19 de janeiro deste mês, foi anunciado o primeiro CPT( Community Tecnical Preview ), de um conjunto de ferramentas que permitirão a criação de aplicações portáteis na plataforma .NET. O CPT pode ser baixado aqui(link para o CPT), mais antes é necessário que você instale o SP1 do Visual Studio 2010( link ctp visual studio ).
Aplicações Portáteis no Visual Studio
Após terem sido instalados tanto Osp1 do Visual Studio, quanto o CTP ferramentas para criação das bibliotecas portáteis, será adicionado um novo template no Visual Studio, conforme ilustra a figura abaixo:
A conjunto de API´s para bibliotecas portáteis, ainda oferece o recurso do desenvolvedor determinar em que plataforma o software irá rodar. É claro vale ressaltar que, existem algumas limitações em relação a certas plataformas, por exemplo XBOX e Windows Phone 7 não tem suporte a MEF por exemplo. É claro que isto não tira a utilidade desta nova API. Abaixo uma tabela de referência para saber o que está disponível, em cada plataforma.
|
Feature |
.NET |
Silverlight |
Windows Phone |
Xbox 360 |
... Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Em um post anterior, falamos do AppFabric Caching e como ele pode nos auxiliar a escalar nossa camada de acesso a dados, em um poderoso cluster de cache, ou seja, um cache centralizado onde não importa se você tem uma aplicação web, windows forms, uma aplicação em WPF ou até mesmo um conjunto de aplicações em uma destas tecnologias, elas poderão compartilhar o mesmo cache; elas irão compartilhar na verdade um cache distribuido. O AppFabric Caching, possui um conjunto de api´s, que podem ser utilizadas, para interagir com o cache armazenando objetos, recuperando objetos, trabalhando com regions enfim para de várias formas manipular o cache. As classes para se trabalhar com o AppFabric Caching, ficam em dois assemblies, são eles : Microsoft.ApplicationServer.Client e Microsoft.ApplicationServer.Core .
Caches O AppFabric Caching, permite que você possa ter múltiplos caches, em seu cluster de cache; isto quer dizer, que você pode ter um cache para cada aplicação, ou, ter tantos caches que você tiver necessidade de criar. E isto pode ser feito através de comandos powershell. Com o comando powershell abaixo, você cria um cache, e é super simples, é só utilizar o comando citado e dar um nome ao cache da sua aplicação.
É preciso notar, se o ServiceStatus do seu cache se como mostra a figura abaixo, se ele estiver DOWN, você irá precisar usar um comando powershell para levantar o ServiceStatus e habilitar o cache criado a ser utilizado. 
Para le
... Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
A extensibilidade dentro da engenharia de software, é algo que a muito é
perseguido, ou seja, ter softwares que sejam plugáveis, tendo assim uma
flexibilidade maior e que seja fácil de modificar e extender mesmo em
tempo de Execução. Como dito no artigo anterior, a extensibilidade é algo que
quando utilizada com sabedoria, é uma ferramenta muito útil para criar
arquiteturas flexíveis, que sejam como por exemplo, como um “Lego” em que exponho
as peças que precisam e elas se acoplam no software facilmente.
A versão 4.0 do .NET Framework , trouxe uma tecnologia chamada MEF – Microsoft
Extensibility Framework. Um framework para criação de aplicativos extensíveis;
uma tecnologia que veio para nos auxiliar a criar softwares que sejam
plugáveis, ou seja, como um “Lego” em que tenho peças que precisam de um
“Encaixe” e outras peças que se “Encaixam” nas mesmas quando necessário. O MEF
também pode ser utilizado como um container de injeção de dependência, servindo
assim como ferramente para realizar a inversão de controle.
Arquitetura
do MEF
O MEF
possui um design, em que a sua arquitetura é dividida em três partes: A camada
em que se encontram os contêineres, ou seja, os repositórios de objetos, uma
camada que direciona o MEF a descobrir as partes, através do que chamamos de
Imports/Exports e finalmente uma camada que contém um Modelo de objetos que são
utilizados como atributos, em que os mesmos serão utilizados para decorar
classes, propriedades e etc.. para que sejam encontradas as partes através de
Imports/Exports. Veja a figura abaixo:
Mecanismo de
Trabalho do MEF
O MEF, é uma
excelente tecnologia para permitir extensibilidade nos aplicativos e torná-los
aderentes a modelo de Plugin. A maneira como o MEF trabalha, é ilustrada pela
figura abaixo:
O MEF
trabalha com catálogos de contêineres. Um contêiner possui um conjunt
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Construir um software que realmente seja orientado a objetos, não é uma tarefa
fácil. Utilizar OO de verdade, exige maturidade, prática e entender seus
princípios, para que se possa utilizar realmente todos os benefícios da
orientação a objetos. O que geralmente acontece, é que os desenvolvedores se
preocupam somente o que é necessário para fazer o software funcionar, e não
considera questões como manutenção, construir algo que seja fácil de modificar
e que siga realmente a Orientação a objetos de fato. Hoje iremos começar a
entender os princípios que são básicos, porém muito importantes para se
construir um software que realmente seja OO; ter decorado conceitos como
herança, encapsulamento e polimorfismo , por exemplo não bastam, é preciso
entender mais profundamente para ter algo de qualidade.
O poder das
Abstrações
Em um
cenário orientado a objetos, a abstração representa uma entidade do mundo real.
Mais sua importância não para por ai, a abstração é uma peça chave não só para
o cenário OO, como também, pare ter um cenário desacoplado; saber utilizar
abstrações, é saber colocá-las em lugares estratégicos que venham viabilizar um
baixo acoplamento. Quando são utilizadas classes concretas ao invés de
abstrações, você cria o que é chamado de forte acoplamento, e que em caso de
mudança, causa um grande impacto e esforço para esta mudança acontecer. Veja o
diagrama abaixo:
Note que a classe abstrata Produto, circulada em vermelho, é a base para
toda classe que for um produto, ou seja, não importa se o produto concreto é um
livro, mochila, caderno, enfim a questão é que todas as classes serão herdeiras
da classe Produto. Dentro de sua arquitetura, a classe que for servir de
base para representar um item do mundo real, tem que conter os principais
conceitos do que se deseja abstrair. Em nosso exemplo, estamos querendo
abstrair, um Produto qualquer do mundo real, e note no diagrama mostrado
anteriormente, que tenho as princípais informações na classe Produto, e
toda e qualquer particularidade, passa a ser da responsabilidade da classe
concreta implementar estes detalhes; vemos no exemplo a classe livro tendo
atributos como ISBN e autor, e a classe mochila t
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Os principais princípios e técnicas de engenharia de software, tem geralmente diversos objetivos, como padronização, organizar componentes, separação de responsabilidades, como também, extensibilidade e composição. A muito tempo que se buscam soluções, que permitam que sejam construídos sistemas que sejam fáceis de se modificar, mais que também, possam serem estendidos com facilidade. O fluxo de mudanças em determinados tipos de negócios, tem uma variação muito grande e os softwares que visam atender os mesmos, caso não sejam fáceis te se estender, adicionando funcionalidades facilmente, certamente irão fracassar.
Atualmente, se vê no cenário mundial de arquitetura de software, um esforço grande em tornar real, este desejo de softwares que sejam fáceis de estender, ou seja, sistemas que sejam como um “Lego”, em que peças são adicionadas com facilidade ao mesmo. Martin Fowler, em seu livro Padrões de Arquitetura de Aplicações Corporativa, apresenta um pattern chamado PlugIn Pattern, que tem a descrição da seguinte forma:
“Conecta classes durante a configuração em vez de na compilação.”
Esta frase simples sobre o pattern, nos dá a idéia central do mesmo. O Plugin, como seu próprio nome diz, tem o objetivo de em tempo de execução, conectar objetos que respeitem um determinado contrato de serviço, e que os mesmos possam ser carregados em tempo de execução. O Plugin pattern, é uma das formas, que podemos utilizar para ter uma arquitetura extensível.
Extensibilidades e Contratos de Serviço É necessário entender que, precisamos estender o que muda, o que varia, ou seja, utilizar a extensibilidade com sabedoria. Para cons
... Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
ORM (Object Relational Mapper) é uma técnica de mapeamento de objeto relacional
que permite fazer uma relação dos objetos com os dados que os mesmos
representam. Ultimamente tem sido muito utilizada e vem crescendo bastante nos
úttimos anos.
Este crescimento,
tem se dado principalmente pelo fato de muitos desenvolvedores não se sentirem
a vontade de escrever código SQL e pela produtividade que esta técnica nos
proporciona. Existem ótimos ORM´s como Hibernate, NHibernate, Entity Framework
e etc.
Tudo começa como mostrado
na figura acima, existem 2 mundos: o relacional e o orinetado a objetos, no
mundo relacional prevalecem princípios matemáticos com a finalidade de
armazenar e gerenciar corretamente os dados, de forma segura e se trabalha com
a linguagem SQL q
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
A uma das grande dificuldades hoje em dia em termos de desenvolvimento de software, esta relacionada a manutenção. Segundo pesquisas, 80% do investimento feito em software está relacionado ao custo da manutenção.O fato de muitos softwares serem construindo sem boa práticas e padrões adequados, ou até mesmo, construídos sem uma sólida arquitetura; acaba por se ter um produto mal feito, um verdadeiro “elefante branco”. Mais ai fica a pergunta: o que torna um software difícil de se evoluir ou manter? Além dos problemas citados anteriormente, o que ocorre, é que o código mal escrito faz com que uma pequena alteração cause outros erros, e isto quando ao solucionar um problema não surja outro. O padrão Open Close Princíple, um dos princípios SOLID, diz o seguinte: “Entidades de software ( classes, métodos, módulo, etc ) devem estar abertas para extensão, mas fechadas para modificação”. A afirmação acima, só pode ser mantida se o software tiver um design concebido sob os pilares das boas praticas de desenvolvimento de software, e isto incluir aplicar padrões e princípios que deem base para um softwares que tenha uma base sólida. Veja o exemplo abaixo, sem ter sido considerado o princípo do aberto/fechado:
Veja que no código acima, temos muitos problemas de design. O principal é que, caso seja feita uma modificação no cálculo do salário, seja a inclusão de alguma fórmula adicional ou qualquer outro fator, pode causar comportamentos ine
...Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Segue a nossa saga de descoberta dos patterns. Hoje iremos falar de um pattern que é até um pouco que polêmico, alguns consideram um anti-pattern, outros o utilizam e veem nele utilidade, iremos procurar abordar quais vantagens, desvantagens e o que pode ser tirado proveito do pattern singleton. Em um artigo falei, que vejo os patterns como uma ferramenta e assim como existe uma ferramenta específica para cada oportunidade, os patterns tem que ser usado com coerência para que venham atender a demanda em um cenário específico. O Singleton é um pattern utilizado, para quando desejamos ter apenas uma instância de um determinado objeto em todo sistema. Imagine a seguinte situação: gerenciamento de cache; por que teríamos mais de uma classe para gerenciar o cache? Ou configuração por exemplo por que ter mais de uma classe de configurações? Em situações como estas, entra a utilidade do singleton. Veja o diagrama abaixo:
Como a imagem acima mostra, o singleton é simples; ele geralmente é uma classe estática que tem uma propriedade chamada instância que armazena uma instância dele mesmo e os métodos para o devido fim em que for aplicado o padrão, gerenciamento de cache por exemplo. Veja abaixo uma implementação do singleton:
...Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Bom pessoal, em mais um de nossos artigos sobre design patterns, falaremos dos padrões factory. Na verdade não existe o padrão factory, e sim padrões chamados factory method e abstract factory. Os padrões factory, tem como principal objetivo nos auxiliar a reduzir acoplamento em nosso software, ou seja, ele vai manter dependências flexiveis e para isto, fazendo com que as dependências deixem de ser explicítas, não podemos esquecer o que Uncle Bob disse: “abstração não deve depender de detalhes, detalhes é quem deve depender de abstrações” . Hoje iremos falar sobre o padrão factory method.
O por que do Factory Method
Como dito anteriormente, a meta é tornar o software mais flexivel retirando assim, as dependências explicítas. O grande problema, é que quando instânciamos diretamente um objeto, estamos criando uma dependência explicíta para o determinado objeto. Pbserve o exemplo abaixo:
var objJogador = new JogadorFutebol(); A primeira vista, pode parecer inofensivo, mais quando se trata de um software mais coplexo com uma hierarquia, por exemplo, esta simples instânciação iria estabelecer uma dependência concreta e custosa de remover; caso fosse necessário mudar de JogadorFutebol para JogadorBasquete, teriamos um problema para alterar o software. Entra em ação então o Factory Method. Em uma arquitetura, ele passa a ser o responsável por criar determinados objetos, reduzindo assim o acoplamento e até nos fazendo utilizar o princípio da responsabilidade única. Veja o diagrama do pattern abaixo:
Como visto acima, temos uma classe base abstrata( criadora ), que contém um método abstrato( factory method ) que cria um determinado objeto( produto ). Utilizando o Factory Method, você cria uma interface para os clientes utilizarem, mais deixa que eles, a responsabilidade de decir qual classe concreta instânciar. Veja o diagrama do Exemplo
... Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Seguindo a nossa série sobre design patterns, hoje falaremos sobre o Template Method. O pattern template method é muito simples, é como se ele montasse o esqueleto de um algoritmo de uma forma abstrata, e deixasse para que as classes concretas realizem as devidas implementações. O Template Method utiliza uma classe abstrata base, que vai encapsular o template do algoritmo em um método, para que as classes concretas possam herdar desta classe e realizar a implementação de determinados passos deste algoritmo. Observe o diagrama abaixo:
O diagrama acima ilustra o que foi dito acima, o template do algoritmo é encapsulado na classe base e as classes concretas podem implementam cada passo dentro do algoritmo, mas o algoritmo em si não muda. vejamos um exemplo de código:
Já no código começamos a entender como aplicar este pattern, vemos que o template méthod é o metodo ProcessaPedido, ele é quem encapsula dentro dele o algoritmo a ser executado, note que existem alguns métodos dentro dele que representam os pa
... Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Design Patterns, atualmente tem sido muito difundidos, em virtude da busca por um código de melhor manutenção, que possibilite o reuso e no desejo de colocar em prática orientação a objetos de verdade. Design patterns não são novos, já existem há algum tempo, são soluções prontas e catalogadas para resolução de determinados problemas. Devemos encarar os design patterns, como se fossem ferramentas em nossa caixa de ferramentas. Hoje veremos o pattern strategy, que visa encapsular famílias de algoritmos e definir uma estratégia para que sejam utilizados no momento certo. O conceito deste pattern segue abaixo:
“Defina uma família de algoritmos, encapsule cada um, e torne-os intercambiáveis. Strategy permite que o algoritmo varie idependente dos clientes que o utilizam.”
O Strategy é utilizado quando você tem um determinado algoritmo, rotina ou algo deste tipo, e que pode mudar em determinadas ocasiões. Suponhamos que você por exemplo tem uma classe de cálculo de juros e que em uma determinada data do ano, a taxa de juros diminui por conta de uma promoção. Então em cenários como este você, utilizaria o Strategy para auxiliar na solução desta demanda sem causar grande impacto para efetuar a mudança. Observe o diagrama do pattern abaixo:
O Strategy com
... Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
O NuGet, que antes chamava-se NuPack, é um gerenciador de bibliotecas para aplataforma .NET; mais você deve estar se perguntando: por que eu preciso de uma ferramenta como está, se tenho uma IDE tão poderosa como o visual studio? A reposta é simples observe a figura abaixo, ela irá te ajudar a entender do que estou falando:
O que aconteceu acima? a versão de uma das dll´s utilizadas pela biblioteca está com a versão diferente, causando assim o erro acima. O NuGet( formamente chamado de NuPack ) visa justamente evitar este tipo de problema, gerenciando as bibliotecas e garantindo que todas as dll´s de um pacote estejam atualizadas para que possam funcionar perfeitamente. O NuGet foi inspirado [projeto em ruby] e pode ser utilizado livremente dentro do visualt studio 2010.
Trabalhando com o NuGet O NuGet pode ser baixado no seguinte endereço: http://nuget.codeplex.com/. Para começar a utilizar o NuGet é muito fácil; após ter baixado o arquivo, ao executar o mesmo será instalado fácilmente, o NuGet é uma extensão para o visual studio 2010. Para você encontrar o NuGet vá em Tools/Library Package Manager conforme a figura abaixo:
Modos de Utilização
O NuGet pode ser utilizado de duas formas; utilizando caixas de dialogo e ele ainda conta com uma console, onde os pacotes podem ser gerenciados atravéz de comandos.
Pacotes no Nuget O NuGet tem um repositório oficial, onde se encontram os pacotes disponíveis, que podem ser baixados, instalados e utilizado. O primeiro passo é visualizar os pacotes disponíveis. Observe a figura abaixo:
Após encontrar o pacote desejado, basta apenas clicar em install, o mesmo será instalado. Quando a instalação do pacote está completa, aparece um icone ao lado do pacote, ao invéz do botão:
No caso do pacote utilizado como exemplo, ao navegar pelosolution explorer, você vê uma referência para o pacote instalado, e se ele tiver alguma referência a outras dll´s, as mesmas também estarão lá e com a respectiva versão utilizada pelo pacote.
O NuGet grava um arquivo chamado packages.config, que contém informações sobre os pacotes instalados no projeto, veja a imagem abaixo:
...Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Bom pessoal hoje, vamos implementar do zero o pattern de arquitetura Registry. O Registry nada mais é do que uma espécie de buscador de objetos, ou seja, um localizador. O Registry sabe onde se encontram os objetos que você precisa, esta é a função dele. Você pode utilizá-lo, quando houver a necessidade de ter um objeto que sabe procurar e achar os objetos que precisam ser localizados e utilizados. O registry também é importante, por que com ele você pode obter inversão de controle, ou seja, você passa a ele o controle e responsabilidade de encontrar os objetos; você apenas solicita a ele e o mesmo retorna o objeto para você. Mais chega de blá, blá blá e vamos meter a mão na massa. Olhe o diagrama abaixo:
Vamos começar a “discecar” a solução. Veja que tenho uma classe registry, que será chamada por qualquer camada, haja vista, o registry também poder ser utilizado como um service locator e desta maneira poder ser acessado por qualquer camada da aplicação. Ele faz uso de um container, que é quem armazena os objetos que implementam as abstrações, o registry irá solicitar o container que resolva uma determinada abstração( inteface ou classe abstrata ); note que estamos aqui utilizando a inversão de controle, o registry não faz referencia a uma implementação, e sim a uma abstração de um contaner. Exitem vários containers no mercado, structured map, castle windsor, unity da microsoft enfim uma infinidade de containeres de ibnjeção de dependência. O fato de apontarmos para uma abstração faz com que, independende do container, o que importa e existir alguém, a quem o registry possa pedir para resolver a abstração. Temos ainda uma classe para nos auxiliar a obter as abstrações e suas repectivas abstrações.
O Registry Veremos o código do registry abaixo:
Note que o container aponta para uma abstração de um container, ou seja, não importa quem ele é o importante é ele ser capaz de resolver a dependência/abstração. Dentro do construtor, é instânciada uma implementação da interface IDIContainer que utiliza o Unity da microsoft para container de injeção de dependência. É responsabilidade do container, armazenar as abstrações( interfaces/classes abstratas) para que possam ser recuperadas quando necessário.
IDIContainer
Como dito anteriormente, a função do container é simplesmente armazenar as abstrações e suas respectivas implementações, Veja o código abaixo:
Veja que o contrato é simples, um método para registrar a abstração, a alguma classe que a implemente, e um método para recuperar alguma classe que resolva, ou seja, implemente uma determinada abstração.
Implementando o IDIContainer A implementação não tem nenhum mistério, precisamos apenas obter as classes e abstrações, referenciados no projeto em que se encontra o container veja o código da implementação para o Unity abaixo:
A implementação consiste apenas em encontrar as classes e abstrações e mapear no container, no caso desta implementação do Unity. Veja no construtor é chamado o método registraClasses, que usa a classe AssemblyHelper para obter todas as abstrações referenciadas no projeto, mapeando para as respectivas implementações. Implementação da interface:
Métodos
Register Type: Registra a abstração para uma implementação.
Resolve: retorna uma implementação de uma determinada abstração.
AssemblyHelper
A classe Assemblyhelper, recupera todas as abstrações e implementações, referenciadas no projeto em que se encontra a implementação do container. É importante para que o registry possa utilizar o container, que você referencie as dll´s em que se encontram as classes e interfaces que você deseja mapear. Código do Assemblyhelper abaixo:
public class AssemblyHelper
{
public IList<Assembly> obterAssemblies()
{
var listAssemblyRetorno = new List<Assembly>();
var objDirInfoRelease = new DirectoryInfo(AppDomain.CurrentDomain.BaseDirectory);
var objDirInfoBin = objDirInfoRelease.Parent;
var arquivoDLL = objDirInfoRelease.GetFiles();
foreach (var fileInfo in arquivoDLL)
{
if (fileInfo.FullName.Contains(".dll"))
{
Assembly objAssembly = Assembly.LoadFrom(fileInfo.FullName);
listAssemblyRetorno.Add(objAssembly);
}
}
return listAssemblyRetorno;
}
public IList<Type> obterClassesPorAssembly(Assembly pAssembly)
{
IList<Type> listaClassesAssembly = new List<Type>();
foreach (var vType in pAssembly.GetTypes())
{
if (vType.IsClass)
{
&nbs
... Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Antes de falarmos de cachê de dados com AppFabric Caching, iremos entender o que é o AppFabric, seus recursos e ai sim o cachê de dados com o mesmo. O App Fabric fornece extensões para o Windows Server, com o objetivo de oferecer melhor infra-estrutura para aplicativos. O primeiro release do Windows Serve AppFabric, está dividido em duas partes:
AppFabric Caching Services: permite escalar sua camada de dados, por exemplo, provendo acesso a informações acessadas freqüentemente, atravéz de um mecanismo de cache distribuido.
AppFabric Host Services: permite rodar e gerenciar serviços criados com WCF( Windows Communication Foundation ) especialmente os que utilizam o Windows Workflow Foundation.
Hoje estaremos falando sobre o AppFabric Caching Services. O AppFabric Caching, até então de codename velocity, permite que se crie um ambiente de cachê, ou seja, um cachê distribuído; com a finalidade de prover acesso rápido e fácil à informações que são constantemente acessadas ou até mesmo armazenar informações de sessão de aplicativos ASP.NET, acelerando desta forma o acesso aos dados.
Cachê Distribuído
A função do AppFabric, é prover um cachê distribuído, ou seja, um cachê que não esteja centraliz
... Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Seguindo o nosso aprendizado sobre os componentes que compoe a arquitetura WPF, hoje falaremos dos eventos roteado. Eventos roteados, são um tipo de evento que ocorre dentro de um programa wpf, talvez você esteja curioso, em saber o que diferencia um evento roteado, de um evento comum na plataforma .NET, ´mais logo ficará esclarecido esta dúvida. Observe o código XAML abaixo:
Que dá origem a tela abaixo:
Note que o código XAML que dá origem a tela, tem o que chamamos de árvore lógica que é a hierárquia em que os elementos são declarados. Um objeto Grid contém o objeto button, que por sua vez contém um StackPanel e assim por diante. Sendo que a árvore lógica, se expande para a árvore visual, em que podemos ter mais objetos, e que muitas das vezes, são objetos não visuais, como mostra a figura abaixo:
Veja que a árvore visual pode assumir várias ramificações, e que nas mesmas, existem objetos que não são visuais mais pertencem a árvore visual, é ai que começaremos a entender o por que dos eventos roteados. Por que o que vemos declarado no XAML, não é o que objtemos em tempo de execução.
Utilizando a ferramenta snoop( que pode ser baixada aqui ), consigo ver toda a árvore visual que obtenho em tempo de execução. Então começamos a entender que, quando clico no botão, posso não estar clicando no OBJETO Button, posso estar clicando em um objeto ButtonChrome ou no OBJETO Image por exemplo. Ainda que o clique não tenha sido no objeto Button, ele precisa ser traduzido em um clique do botão e é ai que entra o roteamento de eventos.
Roteamento de Eventos
Entender a árvore visual, é imprescindível, pois o roteamento de ventos é feito com base principalmente na árvore visual. Eventos rotead
...Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Pessoal, hoje falaremos de mais uma parte importante dentro da arquitetura WPF: os comandos roteados. Os Comandos roteados, são recursos que o WPF introduz, para que você possa conectar controles de interface de usuário a manipuladores( métodos ), que irão executar alguma ação ao serem invocados; sem que haja um alto acoplamento e sem a necessidade, de uma dependência rigida de um para com o outro. Você pode conectar controles como botões, menus ou qualquer outro controle de interface de usuário a comandos roteados. Os comandos roteados possuem três características comuns são elas:
· Elementos chamadores do comando são desassociados do manipulador do comando. Você não precisa ter uma referência direta entre ambos, como no caso de eventos roteados. Ai está o baixo acoplamento, eles não possuem dependência entre eles, garantindo assim o baixo acoplamento( para saber mais acesse o artigo ).
· Comandos roteados irão habilitar ou desabilitar controles da tela, de acordo com o manipulador de comando. É o manipulador do comando quem vai indicar se o comando pode ser executado ou não.
· Comandos roteados, vão poder associar atalhos do teclado, a manipuladores de comando, ou até mesmo outras entradas do usuário.
Para utilizar comandos roteados, você precisa apenas definir a propriedade command, do controle chamador. Observe o exemplo abaixo:
<Button Command="ApplicationCommands.Save">Save</Button>
Viu como é simples? A propriedade Command é suportada por controles como Button, Menu, RadioButton entre outros. Você pode ainda definir um elemento manipulador, utilizando o CommandBinding:
<Window ...>
<Window.CommandBindings>
<CommandBinding Command="ApplicationCommands.Save"
CanExecute="OnCanExecute" Executed="OnExecute"/>
</Window.CommandBindings>
...
</Window>
Note que o Comman
... Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Muito tenho falado sobre boas práticas de engenharia de software. Aplicar boas práticas, nos rende muitos benefícios como manutenção facilitada, um código organizado, dependências mais leves e uma arquitetura pronta para “abraçar” as mudanças, ao invés de brigar com elas. Hoje estarei abordando um dos princípios SOLID, que são princípios que foram introduzidos por Robert C. Martin, ou como é comumente chamado Uncle Bob. Os princpipios SOLID, são cinco princípios de engenharia de software para alcançar os benefícios que falamos anteriormente. Ficou famoso como SOLID, por que são as iniciais dos princípios, e o pessoal percebeu que formava a palavra SOLID e passou a usá-la. Veja abaixo:
Principios SOLID
· S - Sigle Responsability Principle
· O - Open Close Principle
· L - Liskov substitution Principle
· I - Interface segregation principle
· D – Dependency inversion principle
Estaremos abordando neste artigo o Sigle responsability principle.
Combatendo a Classes faz tudo
Uncle bob diz eu seu livro clean code, que se uma classe tem mais de um motivo para ser alterada
... Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
|
Geralmente quando se inicia a saga de um desenvolvedor, foca-se muito linguagens de programação, algoritmos, banco de dados enfim, tudo é muito novo. Queremos ver nosso código rodando, a tela funcionando e posteriormente, uma vez já agindo profissionalmente, ver o nosso cliente feliz. Cokm o passar do tempo nos deparamos com um tempo maior para dar manutenção, códigos que se repetem, concertos que causam erros, ou seja, começamos a ter pesadelos com um mau design de software. Hoje em dia, estudos afirmam que 80% do valor gasto com sofware é relacionado a manutenção de aplicações. Este indice negativo se deve ao fato de muitas vezes, os bons princípios de engenharia de software serem completamente ignorados. Quando isto acontece, os problemas citados anteriormente tiram o nosso sono e o perigoso “monstro monolítico” aparece. Veja a figura abaixo:
A arte de separar conceitos
Quando uma cidade é construida, existe uma preocupação com o sistema de esgoto, água, luz, telefone e etc, e cada uma destas partes que compõem uma cidade existem a aqueles que se preocupam com cada uma destas partes. Em termos de arquitetura de sofware, não é diferente, e é justamente ai, que entra a separação de conceitos( Separation of Concerns – termo em inglês ). Separar conceitos, é na verdade fazer com que uma aplicação seja modularizada, afim de focar resolver um único problema e caso precise realizar algo que não faz parte de sua tarefa, pede a outro módulo para colaborar quando se fizer necessário. A separação de conceitos, pode também ser aplicada a classes, métodos e componente sempre com o fim de que cada parte foque em resolver um único problema.
Separação de Conceitos e as camadas Uma das maneiras de se construir um sistema contemplando a separação de conceitos, é separar a sua aplicação em camadas e fazer com que cada uma delas foque em resolver tarefas apenas de sua responsabilidade. As camadas, separam conceitos de acordo com a sua função dentro de uma arquitetura. Observe a figura abaixo:
É preciso entender, que não basta apenas separar em namespaces, isto é importante mais não é tudo. As camadas precisam interagir entre si, mais com todo
... Exibição do post interrompida. Para ler conteúdo completo, clique aqui |
|
|
| |
|
25/04/2011 11:48:00
2011
2011
6
1
