Arquitetura de Referência Microsoft: Domain Driven Design, Dependency Injection, Cloud e muito mais

imageOlá pessoal!

Neste post e nos seguintes veremos um apanhado geral sobre o e-book gratuito .NET Technology Guide for Business Applications , escrito por Cesar de La Torre e David Carmona. Como seu próprio nome já anuncia, nele é apresentado um guia de tecnologias .Net para a criação de aplicações de negócios. O seu conteúdo discorre basicamente sobre o diagrama abaixo, onde a pilha mais atual de tecnologias para desenvolvimento e infraestrutura Microsoft é apresentada.

Um conceito bastante interessante e recorrente no e-book é que cada sistema ou subsistema tem um cenário de uso e prioridades / atributos de qualidade específicos, de forma que para cada combinação de cenário / prioridade deve-se optar por um subconjunto de uma ou mais tecnologias disponíveis em cada camada da pilha, para cada subsistema da solução, considerando-se trade-offs envolvidos. Seguindo esta linha, em uma mesma solução de negócios seriam implementados mais de um padrão arquitetural, de acordo com a característica específica de cada subsistema. Subsistemas que lidem com o core-business da organização seriam implementados com uma estrutura de camadas aderente ao estabelecido no Domain Driven Design, considerando ainda padrões que promovam baixo acoplamento, como por exemplo, injeção de dependência. Já subsistemas que lidem com manutenção de dados simples, seriam implementados com o LightSwitch, conforme podemos observar na seguinte citação retirada do e-book:

There is no “silver bullet” or a unique right architecture for any given case. You cannot have “a single architecture to rule all the applications or all the subsystems or bounded contexts.” Depending on the priorities of each subsystem (bounded context), you must choose a different approach. It will be a disaster if you use a very simple data-driven approach (CRUD and RAD) for an application that will be evolving and growing its business logic for many years, because eventually the application will get converted into a “big ball of mud,” and that application will be unmaintainable in the long term. However, the opposite is also true. For instance, it doesn’t make sense to build a very simple data-driven table maintenance application implementing a very advanced and “state of the art” architecture, just because you want to use the same “standard approach” for all of your developments. It will be very costly and comparable to “building a bicycle with rocket parts!” Therefore, the right approach for large business applications is “divide and conquer!”

Veremos nos tópicos a seguir cada uma das tecnologias que compõem a camada Client Software da pilha de tecnologias listada no diagrama, e a primeira gama de tecnologias compreendidas em Application Services, até Collaboration and Portals. As demais tecnologias serão discutidas nos próximos posts.

image

Client Software

Como o próprio nome já sugere, as tecnologias que estão sendo listadas na camada Client Software, são àquelas que provem contato direto com o usuário, ou seja, que rodam em um browser, em um device mobile ou diretamente no desktop (Windows), por exemplo.

Você notou que nesta camada não é listado o Silverlight? Isso porque, segundo consta no e-book, a Microsoft dará suporte ao Silverlight por apenas mais dez anos, sendo o HTML5 a linguagem que cumprirá o papel dos containers de aplicações RIA (Rich Internet Application) como o próprio Silverlight e o Flash. No e-book há um capítulo especifico falando sobre as possibilidades de migração do Silverlight para outras tecnologias, afirmando que a transição poderá ser feita aos poucos, dados os anos de suporte remanescentes.

E não se limitando a substituir o Silverlight, o HTML5 é ainda indicado como padrão para atender multi-plataforma e multi-device em soluções Mobile. Neste caso, pode-se optar por duas abordagens. Uma é a utilização do HTML5 como uma aplicação web acessada pelo smartphone via internet. Nesta opção deve-se considerar as desvantagens da impossibilidade de utilização de recursos específicos do aparelho e do fato de este tipo de aplicação não poder ser disponibilizada / pesquisada em uma App Store. A segunda consiste em uma abordagem hibrida, onde ambas as desvantagens da anterior podem ser endereçadas. Nesta, um App “Container” é criado especificamente para cada device, podendo ser publicado nas App Stores disponíveis em cada sistema operacional destino. Um App “Container” funciona uma interface entre o core da aplicação, implementado em HTML5, e o device em si.

O HTML5 também está sendo indicado para a criação aplicações de negócios web, seja ela gerada com o LightSwitch, para aplicações de curto prazo e rápido deployment, ou criada em uma estrutura de camadas MVC (Model, View and Controller), através do ASP .Net MVC, favorecendo atributos de qualidade como a manutenibilidade e a testabilidade, para aplicações de longo prazo ou core business. Outra possibilidade ainda é a associação do ASP .Net MVC com HTML5 e o apoio de bibliotecas JavaScript como o Knockout, Breeze e Durandal, para a criação de aplicações que seguem o padrão SPA (Single Page Application), que provêm maior usabilidade e interatividade com o usuário, minimizando a quantidade de recarga de páginas. A nova biblioteca SignalR, discutida mais adiante neste post, também deve apoiar bastante na criação deste tipo de aplicação.

Ainda além destes cenários, o HTML5 também está sendo adotado pela Microsoft para a camada client de aplicações Office e SharePoint, havendo ainda a possibilidade de publicação dessas aplicações em uma App Store pública e/ou privada, possibilitando assim a criação de um eco sistema de aplicações em torno das ferramentas de escritório, produtividade e colaboração da Microsoft.

Partindo para o mundo desktop, o WPF (Windows Presentation Foundation) é listado como a abordagem de preferência, devido à utilização do XAML (eXtensible Application Markup Language), que possibilita que a publicação de uma versão da aplicação em uma App Store seja feita de forma mais tranqüila. O e-book cita, porém, que o WPF é menos performático que o tradicional Windows Forms, que por sua vez é menos performático que o C++, e que caso não haja um requisito específico para ter um design mais rebuscado ou uma possibilidade futura de publicação em uma App Store, que se use então o Windows Forms, ou ainda o C++ em cenários que requeiram maior performance no lado client, seja em plataforma Mobile ou Windows Desktop.

Application Services

Na camada Application Services são posicionadas todas as tecnologias que suportam e que interagem de alguma forma com as tecnologias client. Em geral, são tecnologias e soluções que rodam no data center da organização, em uma nuvem privada ou pública.

O quadro Web presentation / UI Services, por exemplo, lista os serviços que rodam em cima do IIS (Internet Information Services), provendo aplicações ASP .Net Web Forms, ASP .Net MVC / SPA e ainda o server engine do LightSwitch, que deverá estar presente em servidores hospedem aplicações construídas com o LightSwitch.

Considerando as tecnologias disponíveis para a criação de aplicações web que rodam no lado do servidor, o ASP .Net Web Forms é indicado no e-book para cenários de aplicações que não sejam totalmente data centric, ou seja, que não sejam voltadas apenas a operações CRUD (create, read, update and delete), sendo estas endereçadas pelo LightSwitch, e que também não requeiram total controle sobre o HTML gerado, o que seria melhor endereçado pelo ASP .Net MVC. Comparado ao ASP .Net MVC o ASP .Net Web Forms traria, segundo o e-book, um nível maior de produtividade, por conta dos recursos drag-and-drop disponíveis, embora esta vantagem seja questionada por alguns desenvolvedores.

Já o quadro Services compõe as tecnologias utilizadas para prover serviços back-end para as aplicações que rodam em um browser, em um device mobile ou no deskptop. Cada tecnologia disponível para a criação de serviços é indicada para um determinado cenário. Vejamos a seguir.

O LightSwitch OData Services é indicado para a exposição de serviços para aplicações construídas com o próprio LightSwitch, ou para outras aplicações de baixa complexidade, de curto prazo, que requeiram rápido deployment e que não requeiram manipulação de dados complexas – em geral aplicações CRUD simples. Os serviços LightSwitch OData Services são criados através de recursos drag-and-drop, o que permite que seu desenvolvimento seja bastante produtivo, porém, menos flexível para customizações e manutenções, desta forma não sendo indicado para serviços core de longo prazo ou para cenários de negócios que sofrem alterações constantes.

Como uma alternativa ao LightSwitch OData Services, o ASP .NET Web API é a tecnologia de preferência, segundo o e-book, quando se deseja prover serviços. Além de prover total controle sobre a implementação, ele dá suporte à utilização do protocolo REST (Representational State Transfer) com os formatos de dados OData (Open Data Protocol) e JSON (JavaScript Object Notation), tirando maior proveito do protocolo de transporte HTTP e dos recursos que estão ao redor dele, como por exemplo o cache HTTP.

Já o WCF (Windows Communication Foundation) é a tecnologia recomendada para cenários em que seja necessário utilizar o protocolo SOAP (Simple Object Access Protocol), ou protocolos de transporte não HTTP, como por exemplo, binário e named-pipes. O WorkFlow services, por sua vez, funciona como uma junção do WCF com o WWF (Windows WorkFlow Foundation) e é recomendado para cenários em que se deseje expor fluxos WWF como serviços.

Ainda no escopo de serviços back-end, chama bastante atenção a nova biblioteca SignalR do .NET, que encapsula um novo recurso disponível no HTML5, que é o WebSocket. Através do SignalR é possível que cliente (browser) e servidor se comuniquem de forma continua, facilitando a disseminação de informações em real-time. Com o uso do WebSocket, o servidor pode enviar uma mensagem (push) para cada client no momento que a informação desejada for atualizada. O SignalR provê uma biblioteca JavaScript para o client e uma Class Library para o lado server, de forma que a conexão entre browser e servidor possa ser estabelecida. Há ainda uma inteligência no SignalR que verifica se o browser em que a aplicação está rodando possui suporte ao WebSocket (browsers que suportem HTML5). Caso tal suporte não seja identificado, outro mecanismo equivalente, porém, menos otimizado é escolhido de forma transparente.

Passando para a caixa Collaboration and Portals, encontramos basicamente as tecnologias disponíveis para criação de funcionalidades que tiram proveito do SharePoint. Apps for SharePoint compreende aplicações Full-page, App parts e UI custom actions. Estas são desenvolvidas e hospedadas de forma desacoplada ao SharePoint, sendo possível a utilização de qualquer tecnologia / linguagem de programação que trabalhe com padrões HTML e JavaScript, como por exemplo, HTML5, ASP .Net, PHP, Java, etc. Para que este tipo de aplicação possa ser disponibilizada no SharePoint, é necessário apenas o registro um arquivo manifesto XML, que define algumas propriedades da aplicação no contexto do SharePoint.

Já o Full-trust SharePoint Sites compreende aplicações que requerem permissões administrativas no SharePoint para funcionar. Estas podem ser as tradicionais aplicações do tipo Web Parts e extensões administrativas. Seu uso é recomendado apenas para cenários específicos, quando se quer customizar o SharePoint ou ainda estender sua funcionalidade padrão. Note que nas versões anteriores do SharePoint as Web Parts eram utilizadas para expor funcionalidades no SharePoint, enquanto que agora a recomendação para atender esta mesma necessidade é pelo uso de App Parts, que como mencionado anteriormente, são desacopladas do SharePoint não só em termos de tecnologia, como também com relação à hospedagem. O tipo de aplicações SandBox já não consta no diagrama, pois, segundo o e-book, não terá seu suporte continuado nas versões posteriores a 2013.

Por fim, a caixa SharePoint Services compreende uma biblioteca JavaScript e uma .NET (Class Library) que possibilitam a manipulação de objetos do SharePoint, como por exemplo suas listas, por aplicações client, desde que estas sejam compatíveis com uma dessas tecnologias – JavaScript ou .NET Class Library.

E assim terminamos este primeiro post. Não deixe de conferir o próximo, onde as demais tecnologias serão abordadas. Até lá!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

*