Se você está usando Flex, Ajax, Silverlight, JavaFx, ou outras tecnologias de RIA, a arquitetura básica vai ser muito semelhante… Na maioria dos casos você normalmente terá uma aplicação cliente osiosa e uma camada de serviços distintos no backend. É importante entender essa diferenciação e para compreender que este desempenha um papel importantíssimo na forma como você projeta e constroi suas aplicações.

RIA se presta mais ao desenvolvimento de cliente-servidor, do que o tradicional desenvolvimento web onde o estado é mantido no servidor em uma aplicação ou sessão. O cliente deste modo sabe de si mesmo, e tipos de dados que está solicitando. Será solicitado apenas os dados que precisa do servidor e nada mais. Isto leva frequentemente a uma camada de serviços mais limpa e menos complicado a requisição do servidor, ainda, em alguns casos, uma redução global de carga no servidor.

Arquitetura Cliente-Servidor

É também importante compreender a sub-arquiteturas dentro da arquitetura global da aplicação. Na imagem acima, você tem a comunicação do cliente com o servidor através de camada de serviços. Se você estiver usando AMF, XML sobre HTTP, JSON, ou SOAP, não faz nenhuma diferença neste assunto. Há prós e contras de cada uma dessas citadas e que pode ser discutido no futuro, mas agora estou focado na própria arquitetura. Cada componente da arquitetura, tem uma maior dimensão da sua própria arquitetura. Você pode ouvir pessoas discutindo o uso do MVC em suas aplicações, mas a interpletação do MVC depende de quem está fazendo e essa pessoa explicar de que forma está usando o padrão.

Model-View-Controller (MVC) é um padrão de arquitetura de software onde uma aplicação é quebrada dentro de camadas separadas para um modelo de dados, a interface do usuário (visão), e a lógica do negócio. A lógica, modelo e visões são desacopladas, e comunicam através de um controlador intermediario. Esse padrão permite completamente ambas abstração da lógica e reuso do código/componentes da aplicação. Você pode ler mais sobre MVC aqui.

Num desenvolvimento web tradicional, houve basicamente um MVC singular. Onde as páginas solicitadas fosse manipuladas por um controlador, qual delega como uma página é processada e como os dados são inseridos dentro da visão (ou como dados são recuperados dentro do modelo).

No mundo da RIA, você realmente tem duas camadas de MVC. Existe um MVC dentro da própria aplicação cliente, e um MVC no backend também. Nem todas as aplicações utiliza um MVC formal ou um super framework para manipular o cliente e serviços, mas cada lado tem pelo menos um tipo de funcionalidade do MVC.

O MVC no cliente gerencia a interação entre o usuário e sua interface. Você invoca comandos, atualizações das visões, carrega os dados e etc… O MVC cliente mantém o estado da aplicação, manipula todas as requisições de dados do servidor e controla como os dados são apresentados na visão.

O MVC no servidor manipula as requisições através do cliente. A camada de serviços do MVC, processa as requisições de uma aplicação cliente e delega ações para o servidor. Isto pode significar o salvamento dos dados em um banco de dados, atualizando o sistema de arquivos, algum tipo de tratamento analítico, ou retornando dados para o servidor. A grande diferença aqui é que não existe qualquer interface do usuário. Em vez da interface do usuário, o ponto de vista seria o formato dos dados que está sendo devolvido a aplicação cliente. Neste caso o ponto de vista poderia determinar o formato do resultado (JSON, XML, etc…). Outro benefício de uma camada de serviço diferenciada, é que você já pode ter a infra-estrutura construída para criar uma API pública em cima de suas lógicas de serviços, se você tiver a necessidade (ou vontade) para manter uma.

Não já escolha definitiva da tecnologia para RIA. Você pode fazer muitas coisas legais com muitas tecnologias diferentes. Backends podem ser escritos em Java, ColdFusion, PHP, Rails, .NET, etc… No lado cliente, são estabelecidos frameworks MVC para Flex/Actionscript e Ajax, alguns emergentes, para o Silverlight, e adaptando para frameworks Java para JavaFX. A determinação de ambos, back-end e front-end, deve ser determinada pelas necessidades e capacidades de sua aplicação e também de sua infra-estrutura existente.

Post original de Andrew Trice. Veja aqui.