Esta apresentação é a parte teórica do meu curso de introdução ao desenvolvimento de sistemas com a plataforma .NET. Esta parte do curso busca explicar como são feitos sistemas antigos e como se deve pensar em sistemas novos usando as tecnologias atuais.

1. Módulo 2: Introdução a
arquiteturas modernas
Integrante do curso Práticas
modernas de desenvolvimento de
software utilizando a plataforma
.NET

2. Introdução
Este curso busca mostrar para o aluno uma
visão ampla e um vocabulário mínimo para
que seja possível prosseguir falando
assuntos como Domain-Driven Design, Test-
First Development e muito mais. Com este
entendimento mínimo o aluno conseguirá
ter base para conseguir analisar a
arquitetura de um projeto moderno de
mercado.

3. Introdução
• Este curso falará apenas de sistemas, isto é, programas
feitos para resolver problemas de negócio.
• Outros tipos de sistemas, como jogos ou softwares mais
específicos também se utilizam de alguns conceitos
básicos e universais que serão apresentados neste curso.

4. Software em 2012
• Antigamente os sistemas eram menores. As
ferramentas eram mais restritas e os times
eram menores. As regras de negócio ficavam
nas telas e o eventual acesso a banco de
dados também ficava nas telas.
• Este modelo de desenvolvimento torna o
sistema extremamente mais difícil de
manter, pois as responsabilidades acabavam
por se misturar, aumentando o risco de se
corrigir ou criar novas funcionalidades.

5. Software em 2012
• Com o passar do tempo e com a evolução das
ferramentas de desenvolvimento, as empresas
acabaram notando que era possível entregar cada
vez mais funcionalidades.
• Entregar novas funcionalidades significa também,
saber organizá-las de forma coerente. Entretanto,
a comunidade sempre teve grande dificuldade em
organizar o software de maneira decente.
• Desde os anos 70 surgiram alguns pilares do
software moderno como a orientação a objetos e
a separação de responsabilidades entre as diversas
partes do software.

6. Software em 2012
• O padrão MVC acabou por se popularizar,
espalhando pela comunidade também, a
ideia de separação de responsabilidades
entre modelo de dados, telas e controllers,
que organizam o fluxo de telas.

7. Software em 2012
• Este conceito, que é a separação de
responsabilidades, funciona até hoje. É um pilar fundamental
de qualquer software bem escrito.
• A evolução das ferramentas, como a criação de IDEs mais
completas, a modernização de linguagens de programação, a
evolução dos sistemas operacionais e as fundamentais
melhorias nas capacidades de exibir itens nas telas trouxe
mudanças radicais de paradigmas no desenvolvimento de
software: um novo mundo se apresentava para os
desenvolvedores, que tinha que enfrentar desafios novos
como a programação para Windows, utilização de
mouse, ambiente multitarefas e mais. Esta evolução acabou
aumentando radicalmente os graus de liberdade das
aplicações então desenvolvidas.

8. Software até 2012
• Este aumento de graus de liberdade dos sistemas
aumentou proporcionalmente a complexidade do
código gerado para suportar tudo isso. Novos
problemas de manutenção de código começaram
a aparecer.
• Com a evolução dos sistemas operacionais tanto
de desktop como de servidores, as empresas
começaram a explorar novas possibilidades, como
a troca de dados automatizada entre sistemas,
aumentando novamente a complexidade do
software produzido.

9. Software até 2012
• O número de projetos
fracassados, abandonados ou atrasados era
alto. A comunidade ainda não estava pronta
para trabalhar com coesão e simplicidade.
• Com o passar do tempo e o surgimento de
plataformas como Java e .NET, a comunidade
estabeleceu um norte para conseguir
organizar todo o código produzido e
conseguiu padronizar alguns conceitos
básicos.

10. Software até 2012
• Além de ter havido um grande aumento de criação
de software para desktops, o surgimento da
internet para o grande público revolucionou
também a forma de se construir software
corporativo. O deploy de uma aplicação desktop
sempre é um transtorno e a possibilidade de
colocar cuidar de apenas um ambiente para
realizar o deploy popularizou muito as aplicações
web.
• Porém, esta nova forma de criar sistemas
ocasionou, novamente, uma nova geração de
sistemas sem uma arquitetura decente.

11. Software até 2012
• Os bancos de dados relacionais se tornaram
padrão de mercado e inúmeros sistemas, de todos
os tamanhos, passaram a utilizar bancos de dados
como Oracle, SQL Server, MySQL e muitos outros.
• A capacidade de centralizar a lógica de negócios
em um único lugar fascinou muitos
desenvolvedores, que conseguiram fazer com que
os bancos de dados fossem responsáveis por uma
grande parte da lógica de negócio da aplicação.
Com isso, com a popularização de sistema de
banco de dados, muitos sistemas contavam com
uma quantidade brutal de código em procedures.

12. Software até 2012
• A comunidade foi amadurecendo. Os times
foram crescendo a necessidade de entregar
valor foi crescendo. A lógica muito espalhada
ou muito centralizada acabou por dificultar
brutalmente a manutenção dos
sistemas, fazendo com que estes muitas
vezes fossem refeitos do zero. Lógica
espalhada por cada página ou lógica
centralizada no banco de dados torna a
manutenção e a paralelização de tarefas
árduas.

13. Software até 2012
• A comunidade chegou ao conceito de
separação de responsabilidades mais formal,
trazendo à tona o conceito de aplicações em
camadas e a necessidade de organizar as
diferentes partes a aplicação de forma
adequada.
• Alcançando uma adequada organização do
software de forma padronizada, grande parte
da comunidade tem se beneficiado de uma
forma inteligente, otimizada e universal de se
desenvolver software.

14. Conceitos Iniciais: Fluxo de dados
• A maioria absoluta dos sistemas trabalham
com dados. Uma forma simples de entender
um sistema é analisando o caminho que a
informação percorre dentro do sistema. Em
geral, a informação é criada na camada de
apresentação, processada pela camada de
negócio e persistida em um banco de dados.
E faz o mesmo caminho para retornar para o
usuário.

15. Conceitos Iniciais: Fluxo de dados
• Conhecendo o caminho que a informação
percorre no sistema, é possível
compreender com facilidade como é a
arquitetura do sistema.

16. Conceitos Iniciais: Camadas
• Ao desenhar o fluxo de dados da aplicação, a
informação poderá passar por uma, duas ou
máquinas do começo ao fim. Estas máquinas,
onde a aplicação roda, são consideradas camadas
físicas. Como exemplo de camadas físicas,
podemos citar servidores web, servidores de
aplicação, servidores de aplicação, celular, browser
de um desktop, etc – a camada física é onde a
aplicação fisicamente é executada.
• Uma aplicação atual típica costuma ter um
servidor web, um servidor de banco de dados e
um browser rodando no desktop do usuário final.

17. Conceitos Iniciais: Camadas
• Ao desenhar o fluxo de dados da aplicação, a
informação poderá passar por uma, duas ou várias
máquinas físicas do começo ao fim. Estas
partes, onde a aplicação roda, são consideradas
camadas físicas. Como exemplo de camadas
físicas, podemos citar servidores web, servidores
de aplicação, servidores de
aplicação, celular, browser de um desktop, etc – a
camada física é onde a aplicação fisicamente é
executada.
• Uma aplicação atual típica costuma ter um
servidor web, um servidor de banco de dados e
um browser rodando no desktop do usuário final.

18. Conceitos Iniciais: Camadas
• Um sistema típico possui pelo uma camada de
apresentação e uma camada de negócios e outra de
acesso a dados (comumente conhecida por
persistência). Estas camadas são chamadas de
camadas lógicas. A camada lógica, ou simplesmente
camada na visão do desenvolvedor, representa a
separação básica de responsabilidade do software. Por
exemplo, a camada de apresentação é responsável por
toda a interação browser-servidor web, mecânica de
tela, validação de entrada de dados e correlatos.
Mesmo que a aplicação tenha uma versão web e outra
mobile, ainda assim a aplicação só terá uma única
camada de apresentação.

19. Principais camadas
• As principais camadas são:
– Apresentação
– Negócio / Serviços
– Acesso a dados
– Infraestrutura
• Ao utilizar a plataforma .NET, é possível
trabalhar utilizando C# na maioria das
camadas da aplicação.

20. Arquitetura 3 camadas
• A maioria dos sistemas construídos desde a popularização da
plataforma .NET utiliza a divisão em 3 camadas:
apresentação, negócio e acesso a dados.
• Este estilo de arquitetura é de longe o mais conhecido na
comunidade.
• Este padrão conseguiu fazer com que as empresas
aumentassem as equipes, permitindo paralelismo de tarefas e
aumentando a quantidade de software entregue. Este padrão
fez bastante sucesso na comunidade e se tornou o padrão de
projetos das consultorias e empresas.
• Para suportar as necessidades atuais de software, o
paradigma de aplicações 3 camadas acabou não sendo
suficiente.

21. Arquitetura N-Camadas
• A arquitetura 3 camadas tradicional não atende
aos novos requisitos de software, como por
exemplo, a criação de software testável, orientado
a domínio, flexível e simples de manter.
• Quando se fala em N camadas, fala-se de
múltiplas camadas lógicas, claras e bem definidas,
que destrincham melhor as camadas do modelo 3-
camadas.
• A separação do software em responsabilidades
ainda menores e mais bem definidas tem sido uma
tendência mundial da comunidade.

22. Camada de Apresentação
• No mundo .NET, as camadas de apresentação
têm evoluído de forma brutal nos últimos 5
anos. Hoje em dia a aplicação pode ser
construída como:
– ASP.NET Web Forms / ASP.NET MVC
– Silverlight
– WPF
– Windows Forms
– Console Application

23. Camada de Apresentação
• As aplicações web dominaram o mercado de software
corporativo e um dos motivos do sucesso da
plataforma .NET é a relativa facilidade em se construir
aplicações web em pouco tempo.
• Hoje em dia, com o ASP.NET MVC a maior facilidade
para se trabalhar com código client-side, o
desenvolvedor precisa conhecer
Javascript, jQuery, HTML(5), CSS(2.1 e 3.0) e diversos
frameworks e tecnologias auxiliares, como por
exemplo, Ajax. Isto faz com que o desenvolvimento
web seja desafiador, porém, muito interessante por ter
uma abrangência quase universal – a maioria dos
dispositivos modernos consegue processar aplicações
web criadas com padrões atuais de HTML, Javascript e
CSS.

24. Camada de Apresentação
• Com .NET, também há opções para ambientes que rodam somente
Windows. Como a vasta maioria dos clientes corporativos utiliza o
Windows como sistema operacional, há grandes chances de ser
possível utilizar estas outras opções para construir sua aplicação.
• A Microsoft oferece a possibilidade de trabalhar com dispositivos
móveis utilizando a plataforma Windows 8, que compreende tablets,
celulares e desktops. É possível criar Metro-style applications que
suportam o .NET 4.5 e se utilizam uma versão nativa da tecnologia
empregada no Silverlight e WPF: XAML. Outra vantagem de se criar
apps para Windows 8 é que é possível programar tanto em C#
quanto Javascript e C++. AS aplicações Metro rodam nativamente e
não utilizam o .NET – elas utilizam o WinRT, que é uma atualização
do Win32 e que suporta o mesmo estilo de bibliotecas do .NET.

25. Camada de Negócios
• As regras de negócio devem ficar no código fonte e
não mais no banco de dados. As regras também não
podem ficar armazenadas na tela.
• A camada de negócios é responsável por orquestrar o
acesso a recursos como banco de dados, webservices
externos e é responsável também por retornar ao
usuário a resposta de suas requisições. Vale notar que
a aplicação é responsável por aceitar imediatamente
as requisições do usuário e não
necessariamente, precisa retornar a resposta da
requisição imediatamente. A camada de negócios é o
coração da aplicação em qualquer tipo de arquitetura.

26. Camada de Acesso a Dados
• Como dito anteriormente, quase todos os sistemas trabalham
com dados. A camada de acesso a dados recebe comandos da
camada de negócios e providencia acesso aos dados
guardados no banco de dados.
• Antigamente o código de acesso dados era muito
tedioso, repetitivo e suscetível a erros. Basicamente, os
desenvolvedores escreviam comandos SQL para operações
CRUD e lógicas avançadas eram feitas chamando procedures.
A comunidade acabou criando ferramentas chamadas OR/Ms
- object-relational mapping. Estas ferramentas conseguem
fazer com que a aplicação veja tabelas do banco de dados
como classes, simplificando o código de acesso a dados em
90% - hoje em dia não é mais necessário montar comandos
SQL dentro do código-fonte. Um OR/M consegue gerar
comandos SQL automaticamente.

27. Camada de Acesso a Dados
• Os OR/Ms mais populares são: NHibernate e Entity
Framework na comunidade .NET. Há muitos
similares, pagos e gratuitos, mas geralmente só se
pensa nestas duas opções ao criar escolher um OR/M.
• O NHibernate é mais maduro e oferece uma maior
gama de configurações para melhorar a performance
da aplicação.
• O Entity Framework tem recebido atualizações
constantes da Microsoft – o seu ciclo de
desenvolvimento não é atrelado às versões do .NET –
ou seja – a Microsoft tem trabalhado com a
comunidade para gerar versões mais rapidamente e
focando no que a comunidade tem pedido.

28. Camada de Acesso a Dados
• O uso de LINQ é suportado pelas duas
ferramentas – é possível montar consultas usando
sintaxe parecida com SQL para gerar consultas no
banco de dados.
• Ambos suportam os bancos de dados mais
comuns do mercado, como Oracle, SQL Server e
MySQL.
• A utilização de OR/M acelera bastante o
desenvolvimento e desfavorece a colocação de
lógica complexa no banco de dados – todos os
dados que chegam do banco de dados precisam
ser mapeados para uma classe da aplicação.

29. Camada de Acesso a Dados
• Nos últimos anos, uma nova tendência surgiu no mercado - a utilização de
banco de dados NOSQL.
• NOSQL é interpretado normalmente como “not only SQL” – na prática, isto
significa que a tecnologia de persistência de dados não necessariamente é
um banco de dados clássico, como SQL Server ou Oracle – hoje em dia há
múltiplas classes de bancos de dados, que rompem completamente com o
modelo relacional para serem bons em alguma área específica.
• Com o uso de NoSQL, é possível criar aplicações extremamente rápidas,
poderosas, flexíveis e fáceis de manter. Esta tendência está mudando
radicalmente a forma de pensar no acesso a dados de uma aplicação
moderna.
• Ultimamente, provedores de serviços de storage e servidor na nuvem
oferecem novas possibilidades de se trabalhar com informações de formas
simples e com alta performance. Em 2012, as opções para construir software
moderno são brutalmente mais abundantes que há 10 anos atrás.

30. Camada de Serviços
• Um sistema pode expor seus dados e sua lógica para o mundo
externo sem precisar de uma camada de apresentação. Com isso,
outros sistemas podem consumir estes dados.
• A forma mais comum de trocar dados entre sistemas via
intranet/internet é através da utilização de web services.
• As trocas de dados entre sistemas precisam aderir a um padrão de
formato de mensagem para que software construído em qualquer
plataforma consiga consumir serviços de outra plataforma qualquer.
• O crescimento da internet e a popularização de tecnologias como
SOA e REST faz com que a camada de serviços da aplicação hoje em
dia seja muito mais complexa, pois ela pode ter que lidar com
problemas de segurança, cache, operações de longa duração, uso
de múltiplos servidores de aplicação entre outros tipos de desafios.

31. Camada de Serviços
• Os serviços expõem dados utilizando XML ou JSON. O
uso de XML é comum em aplicações corporativas, que
exigem um formato de dados rígido que também está
no mercado há mais tempo. Aplicações modernas para
a internet aberta são construídas utilizando JSON, que
é um formato de dados mais simples, leve, flexível e
fácil de se trabalhar com Javascript e demais
frameworks de mercado.
• A utilização de serviços mais simples, que trabalham
com JSON é o padrão para aplicações mobile e AJAX –
estas dependem de tráfego de dados otimizado para
situações de internet lenta e intermitente.

32. Camada de Infraestrutura
• Os sistemas geralmente dependem de
outras coisas para trabalhar. É raro
encontrar uma aplicação que só tenha as
três camadas básicas. Serviços de e-mail,
log, segurança e correlatos são
considerados parte da camada de
infraestrutura – estes podem ser utilizados
por qualquer outra camada.

33. Arquiteturas orientadas a dados
• Uma parcela enorme dos sistemas que estão no ar e mesmo
os que estão construídos foram pensados utilizando o
conceito de modelo de dados.
• Neste modelo, as tabelas e seus relacionamentos guiam toda
a arquitetura da aplicação. As entidades da aplicação são as
mesmas entidades do banco de dados.
• Embora bem sucedido até para projetos maiores, a sociedade
notou que a manutenção destes sistemas acaba sendo muito
cara – mudanças simples como adição de uma coluna
provocam alterações em múltiplas classes.
• Para aplicações simples, muitas vezes a camada de negócios
não faz absolutamente nada – este fato é muitas vezes faz
com que o desenvolvedor iniciante pense que é inútil ter uma
camada de negócios.

34. Arquiteturas orientadas a dados
• Muitas empresas criaram geradores de código para “automatizar” a
produção de um código em geral muito repetitivo. Logo, a alteração
do código gerado provoca outro custo de manutenção. Este
problema é suavizado com a utilização de um OR/M.
• Para o desenvolvimento orientado a dados, o banco de dados passa
a ser o centro de gravidade da aplicação – o resto da aplicação serve
apenas de ferramenta para cadastrar e utilizar informação.
• O desenvolvimento orientado a dados não favorece a testabilidade
do sistema – geralmente é muito difícil testar a lógica de negócios
do sistema de forma isolada – a maioria dos testes viáveis acabam
de alguma forma tocando o banco de dados, tornando-se testes de
integração mais lentos.
• O código gerado por uma arquitetura destas não é orientado a
objetos. Este tipo de sistema é simplesmente uma sequência de
procedimentos para escrever no banco de dados.

35. Arquiteturas orientadas a domínio
• Como uma resposta aos efeitos colaterais das
arquiteturas orientadas a dados, a comunidade
trouxe à tona o DDD (Domain-Driven Design)
• Esta metodologia é uma mudança dura e brutal de
paradigma – o banco de dados deixa de ser o
centro da aplicação.
• O domínio, isto é, o problema que a aplicação
resolve vira o centro de gravidade da aplicação.
Esta mudança faz, na prática, que o banco de
dados fique no mesmo nível de outros serviços – é
apenas um item que o domínio utiliza para
resolver o problema de negócios.

36. Arquiteturas orientadas a domínio
• O DDD é uma forma mais complexa de se desenvolver software.
Entretanto, esta metodologia é focada na construção de sistemas
que sejam orientados a objetos, fáceis de manter, fáceis de testar e
com responsabilidades muito bem definidas. Ou seja: há uma trade-
off entre esforço de desenvolvimento e custo de manutenção no
futuro. Para empresas com produtos próprios e duradouros, faz
muito sentido pensar na aplicação de DDD e suas técnicas.
• O DDD traz consigo muitas práticas interessantes de
desenvolvimento de software, como TDD (Test-Driven Development)
e o desenvolvimento ágil. Com isso, só se constrói software que
realmente será utilizado pela aplicação final, nem mais nem menos.
O código produzido com TDD tende a ser muito mais
legível, simples e focado em trazer resultados mais concretos e
óbvios.
• O código orientado a domínio é orientado a objetos e tende possuir
um acoplamento muito inferior ao visto nos sistemas orientados a
dados.

37. Exemplo: Arquitetura 3 camadas
focada no banco de dados
Apresentação
Legenda:
O projeto A utiliza o projeto B
Infraestrutura
Negócio A
B
Acesso a dados

38. Exemplo: Arquitetura n-camadas
focada em domínio

39. Organização da camada de apresentação
• Ao iniciar um projeto do zero, além de
decidir quais camadas e qual metodologia
será utilizada, é necessário, entre várias
outras decisões, estabelecer como será a
estrutura da camada de apresentação.
• Esta decisão é importante pois pode ser a
diferença entre ter um projeto simples ou
complexo de manter.

40. Organização da camada de apresentação
• Algumas tecnologias, como Windows
Forms e ASP.NET Web Forms permitem as
criação de arquivos code-behind. Este
arquivo é necessário para que seja possível
responder a eventos como click, double-
click e também, eventos de componentes.
Este tipo de código é orientado a eventos
e tende causar um enorme acoplamento
tela-regra de negócio, pois todas as ações
são tomadas utilizando eventos de tela.

41. Organização da camada de apresentação
• O uso de code-behind prejudica a
testabilidade de código. Regras de
negócio misturadas com eventos de tela é
a receita perfeita para criar sistemas
impossíveis de manter.
• A maior parte dos novos desenvolvedores
simplesmente não entende a motivação
do código existente. Logo, código recém-
criado acaba piorando mais ainda a
situação, levando o sistema a um caos.

42. Organização da camada de apresentação
• Para trazer sanidade ao desenvolvimento do
front-end, a comunidade criou vários padrões
estruturais adequados para cada cenário. São
eles:
– MVC – Model-View-Controller
– MVP – Model-View-Presenter
– MVVM – Model-View-ViewModel.
• Basicamente estes padrões servem para
trazer uma separação básica entre a lógica
que manipula a tela, dados que alimentam a
tela e os fluxos da aplicação.

43. Organização da camada de apresentação
• A View é o que aparece na tela em si. No
mundo do .NET temos:
- ASP.NET Web Forms -> .aspx
- ASP.NET MVC -> .cshtml
- Silverlight/WPF -> .xaml
- Windows Forms -> um Form simples
- Das citadas acima, só o ASP.NET não
permite code-behind – mas permite
código inline no HTML.

44. Organização da camada de apresentação
• O Controller, Presenter ou ViewModel é responsável
por servir de elemento intermediário entre a View e os
dados da aplicação.
• Esta intermediação ajuda a deixar a View limpa,
permitindo que a View só se preocupe em mostrar os
dados vindos do sistema e claro, consiga fazer o
trabalho de aceitar um input válido do usuário final.
• A comunicação Controller para View tem evoluído
muito no mundo .NET. O sistema de binding do WPF,
MVC e até mesmo Web Forms (.NET 4.5) trouxe uma
grande facilidade de se aplicar databinding neste
processo de passar dados, diminuindo brutalmente a
quantidade de código tedioso necessário para
alimentar uma view.

45. Organização da camada de apresentação
• A definição de Model hoje em dia é
relativamente turva. O Model, tecnicamente
falando, é a classe do .NET que o Controller
usa para alimentar a View com dados.
• Muitas aplicações não possuem classes
específicas para representar os dados de uma
tela – por praticidade algumas equipes
utilizam as próprias classes de domínio para
fazer o binding na view. Nestes casos, o
Model passa a ser o domínio da aplicação.

46. Boas práticas
• Primordial: sempre que for iniciar uma
aplicação séria, com múltiplas telas e
fluxos, utilize DDD e TDD. O mercado cada
vez mais glorifica os benefícios destas
técnicas, que vão em consonância com
metodologias ágeis de desenvolvimento de
software que norteiam a comunidade hoje
em dia.
• As boas práticas descritas daqui em diante
precisam ser avaliadas – o custo e o benefício
podem variam em cada caso.

47. Boas práticas
• Para diminuir o acoplamento entre as camadas,
utilize Dependency Injection. Este padrão faz com
que cada classe receba pronta toda as suas
dependências, sem se preocupar em criar
instâncias das mesmas.
• Ao passar dados entre as camadas, utilize classes
específicas para este fim. Sempre que possível, crie
um DTO (Data Transfer Object) para passar os
dados. Considere passar somente dados
estritamente necessários para atender a requisição.
Utilize uma ferramenta para fazer o mapeamento
automático em todas as situações.

48. Boas práticas
• O mesmo vale para as camadas de apresentação. Uma forma comum de se
trabalhar é utilizando ViewModels, que são classes que possuem só e
somente só os campos que a View vai utilizar. Mesmo que uma entidade
principal do domínio se pareça muito com o modelo de uma view, ainda
assim compensa criar uma ViewModel – há um ganho de liberdade para
poder evoluir em separado o código da ViewModel sem afetar o domínio. E
vice-versa. Em geral, utilize uma ViewModel por View.
• Quando o domínio da aplicação deve depender apenas de interfaces que
representam o recurso a ser utilizado. Estas interfaces (sim, interfaces do C#)
funcionam como contratos nos quais o domínio pode confiar para por
exemplo, enviar um e-mail, utilizar um banco de dados e etc. Esta técnica
diminui bastante o acoplamento entre as partes da aplicação. Outra
vantagem é que o uso desta técnica permite a substituição de um recurso
externo por um objeto falso. Este aumento de facilidade ao testar é
fundamental para gerar um código mais bem escrito e decente. Por
exemplo, é possível criar um teste que use dados falsos de um banco de
dados falso para exercitar uma lógica de domínio. Estes objetos fajutos
implementam a mesma interface do recurso real, o que para o domínio da
aplicação é transparente.

49. Boas práticas
• Crie testes unitários e de integração. Utilize
ferramentas como NUnit e Moq para ajudar a
automatizar os testes unitários. Não construa
testes unitários que toquem o banco de dados – a
velocidade tende a cair muito. Utilize test doubles
sempre que possível.
• Utilize ferramentas open-source em seu projeto.
Um aplicação moderna depende de múltiplos
frameworks e projetos que automatizam e
simplificam processos repetitivos e braçais.
Utilizando ferramentas de terceiros com código
aberto, é possível cogitar na possibilidade de
alterar a implementação da ferramenta.

50. Boas práticas
• Ao optar por design patterns de UI, pense
nos seguintes padrões:
– ASP.NET Web Forms: utilizar MVP
– Windows Forms: utilizar MVP
– ASP.NET MVC: utilizar MVC
– Silverlight, WPF: utilizar MVVM