Introdução a arquitetura de sistemas com .NET

2,245 views

Published on

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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,245
On SlideShare
0
From Embeds
0
Number of Embeds
511
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Introdução a arquitetura de sistemas com .NET

  1. 1. Módulo 2: Introdução aarquiteturas modernas Integrante do curso Práticasmodernas de desenvolvimento desoftware utilizando a plataforma .NET
  2. 2. IntroduçãoEste curso busca mostrar para o aluno umavisão ampla e um vocabulário mínimo paraque seja possível prosseguir falandoassuntos como Domain-Driven Design, Test-First Development e muito mais. Com esteentendimento mínimo o aluno conseguiráter base para conseguir analisar aarquitetura de um projeto moderno demercado.
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 38. Exemplo: Arquitetura n-camadas focada em domínio
  39. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×