Este é um post disponível para assinantes MVPWPF para aplicações comerciais – Parte 2 - .Net Magazine 75
A Microsoft criou o WPF inicialmente como uma plataforma para desenvolvimento de aplicações multimídia. Porém a comunidade de desenvolvedores o abraçou para o desenvolvimento de aplicações comerciais, também conhecidas como LOB (line-of-business). Neste artigo vamos continuar o exemplo iniciado na primeira parte, mostrando como separar as camadas do sistema, como validar objetos e como customizar controles.
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 75
WPF para aplicações comerciais – Parte 2
Vamos
nos posicionar em relação ao que já está feito. Terminamos a primeira parte do
projeto com a camada de apresentação, serviço e acesso a dados pronta. Porém
não estão totalmente operacionais. Vamos começar a colocar as coisas em ordem.
Service Locator
Para
unir as interfaces anteriormente criadas (IDao e IServicoContato) com suas implementações vamos fazer uso de um
container IoC (inversão de controle). Nesse container será possível registrar
qual classe concreta que implementa as
interfaces definidas até agora. Assim, ao invés de nós mesmos instanciarmos
essas classes, vamos pedir ao container IoC que as crie, fazendo isso, o
container pode identificar dependências dessas classes e já resolvê-las para
nós, isso é que chamamos de DI
(Dependecy Injection) ou injeção de dependência. Para entender melhor o que é
essa dependência, olhemos o construtor da classe ServicoNHContato:
public ServicoNHContato(IDao
{
_contatoDao = dao;
}
Veja
que temos a exigência de um parâmetro do tipo IDao. Essa é uma dependência da
classe ServicoNHContato. O container IoC é capaz de identificar isso e, ao
solicitarmos que um objeto desse tipo seja instanciado, automaticamente uma
instância de IDao também e criada e passada como parâmetro, para satisfazer a
exigência. Tudo isso será transparente para nós, não será necessário que nós
criemos um IDao, o container IoC fará isso para nós, desde que tudo esteja
corretamente registrado.
Nota: Vamos utilizar o
Windsor do projeto Castle como container IoC. Para fazer seu download veja a
sessão Links.
Para
centralizar o acesso a esse container, vamos utilizar um padrão chamado Service
Locator. Seu objetivo é ser o único caminho para obter a implementação
(instância de uma classe) de um dado serviço (interface). Além disso, ele
também é responsável por fazer a configuração inicial do container IoC, sendo
assim na Figura 1 podemos ver um
diagrama de classes que mostra sua estrutura e uso.
Para
criar nosso Service Locator vamos utilizar como base a classe definida pela
equipe do Microsoft Practices & Patterns, que está hospedada no CodePlex
(veja o download na sessão Links). Abra
no Visual Studio 2010 o projeto anteriormente feito e adicione na pasta
Servicos uma nova classe chamada ServiceLocator.cs. Feito isso adicione o
código da Listagem 1 e vamos
entendê-lo melhor.
Nota: Adicione no using os
seguintes namespaces:
using
Microsoft.Practices.ServiceLocation;
using NHibernate;
using uNhAddIns.CastleAdapters;
using
uNhAddIns.CastleAdapters.AutomaticConversationManagement;
using uNhAddIns.SessionEasier;
using
uNhAddIns.SessionEasier.Conversations;
using
Castle.MicroKernel.Registration;
using Castle.Windsor;
using
CommonServiceLocator.WindsorAdapter;
using AgendaWPF.AcessoDados;
Listagem 1. Service Locator
01 public class ServiceLocatorProvider
02 {
03
public static
void Initialize()
04
{
05
var container = new
WindsorContainer();
06
container.AddFacility
07
container.Register(Component.For(typeof(IDao<>))
08 .ImplementedBy(typeof(BaseDao<>"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
2 COMENTÁRIOS
o link do codigo fonte está indisponivel, for favor verificar.
muito obirgado.
Obrigado e um abraço
Space do autor


0
0
