Como arquitetar aplicativos de desktop corporativos para Windows 8

Acho que tenho uma noção das expectativas do desenvolvimento de aplicativos para o consumidor no Windows 8. Crie uma nova interface do usuário baseada no Metro sobre o WinRT, implante-a no seu cliente através do Marketplace, e todos vencerão. Parece bastante simples. Infelizmente, eu não estou nesse negócio.

Trabalho em aplicativos internos de linha de negócios para uma grande empresa. Atualmente, usamos tecnologias .NET como WPF e Silverlight para criar UIs ricas que podem ser facilmente implantadas para nossos usuários via web ou ClickOnce. Os aplicativos podem suportar WinXP e Win7 sem muita dor de cabeça, e nossos desenvolvedores usam o XAML, que é uma tecnologia de interface do usuário muito sólida.

Parece que o WPF e o Silverlight têm futuros questionáveis ​​neste momento, por isso é um pouco preocupante continuar investindo neles. Mas uma interface do usuário do Metro não parece apropriada para aplicativos corporativos, e a API do WinRT é bastante limitadora em relação às coisas "típicas" que os aplicativos corporativos precisam fazer.

Como devo arquitetar meus aplicativos baseados em XAML, atualmente sendo implantados no WinXP e Win7, para que eles sejam suportados e evoluídos no Win8?

Suponhamos, para os fins desta pergunta, que os recursos fornecidos pelo HTML5 no ASP.NET não sejam adequados para os aplicativos que pretendo criar. Entendo que posso usar HTML5 para alguns aplicativos, mas estou tentando descobrir o que devo fazer quando isso não for suficiente.

Editar # 1: isso é uma resposta ao comentário de @Emmad Kareem. Concordo que o Silverlight / WPF seja viável a curto prazo (2-5 anos). No entanto, as aplicações que produzimos têm vida útil potencialmente muito longa (10 a 20 anos). Portanto, a capacidade de sobrevivência a longo prazo de uma determinada tecnologia é uma preocupação para nós. Além disso, temos alguma preocupação de que será cada vez mais difícil encontrar desenvolvedores interessados ​​no desenvolvimento do Silverlight / WPF se essas tecnologias forem consideradas "mortas" pela comunidade. Eu só quero entender minhas opções e tomar uma decisão com os olhos abertos.

Como eu aprendi a parar de se preocupar e amar o MS-Stack

Você ainda pode executar aplicativos VB6 no Windows 8 . A compatibilidade retroativa para boa ou ruim sempre foi uma tendência no ecossistema da EM. Você não deve se preocupar com a sobrevivência de tecnologias como WPF / Silveright e até mesmo com formas de win.

Por outro lado, você precisa aceitar que, para um projeto de longo prazo, nunca terá a tecnologia mais recente e fofa.

De fato, as perguntas que você deve fazer sobre a escolha de uma tecnologia são:

• Minha equipe está confortável o suficiente com essa tecnologia para ser produtiva?
• Minha equipe está feliz em usar essa tecnologia?
• Posso recrutar pessoas para essa tecnologia?

Essa é a combinação das respostas a essas perguntas que deve levar sua escolha, e não as tendências criadas principalmente por razões de marketing.

Para saber mais sobre essa temática da tecnologia em constante mudança, leia "Fire And Motion", de Joel Spolsky :

As empresas que tropeçam são as que gastam muito tempo lendo folhas de chá para descobrir a direção futura da Microsoft. As pessoas ficam preocupadas com o .NET e decidem reescrever toda a arquitetura do .NET porque acham que precisam. A Microsoft está atirando em você, e é apenas encobrir o fogo para que eles possam avançar e você não, porque é assim que o jogo é jogado, Bubby. Você vai apoiar o Hailstorm? SABONETE? RDF? Você o apoia porque seus clientes precisam ou porque alguém está atirando em você e você sente que precisa responder? As equipes de vendas das grandes empresas entendem o incêndio.

E isso foi escrito há quase dez anos.

Arquitetura e Tecnologias

Arquitetura e tecnologias são duas coisas e opções separadas a serem feitas:

• Você pode fazer MVC com winforms .
• Você pode fazer o MVVM com WPF / Silverlight .
• Você pode fazer o MVC com o ASP.NET .
• Você pode fazer o que quiser, incluindo MVC e MVVM, com o WINRT até onde sabemos .
• Você pode funcionar com o F # . Por que não ? Existem domínios em que isso faria sentido.
• Você pode misturar todos eles, ter diferentes pontos de entrada em um sistema comum e ser ridicularizado porque fica muito complicado etc.

Você pode usar serviços, recursos, controles de terceiros, ORMs etc. com todas essas tecnologias e talvez, ou talvez não, com as próximas.

Você pode torcer e dobrar o MVC de várias maneiras com todas essas tecnologias: vinculativa ou não? código por trás da vista ou não? Controlador ou não? ViewModel sempre ou apenas quando necessário? Existem muitas maneiras de implementar um padrão de design, mesmo dentro do escopo de uma tecnologia específica.

Seria irrealista forçá-lo a entrar em um deles sem conhecimento avançado de seu projeto e equipe. Seria apenas baseado em preferências pessoais e terminaria no confronto "minha tecnologia é melhor que a sua".

A única coisa que pode ser sincera e objetivamente sugerida é usar as melhores práticas que você pode aplicar para criar uma arquitetura que resista ao teste do tempo e talvez seja realmente portátil ou reutilizada pelo menos em partes de uma futura tecnologia desconhecida . E essa capacidade de atualização / portabilidade nem deve ser o principal objetivo da sua arquitetura.

O principal objetivo de sua arquitetura e tecnologia escolhida é entregar um produto ao seu chefe / cliente que atenda aos requisitos realistas dele.

O MVC (e seu irmão mais novo, MVVM) provou cada vez mais ser uma base para uma arquitetura robusta desde 1979 na arena de idiomas OOP e além. Mas a escolha de qual tecnologia específica deve ser usada em um projeto de 10 anos deve permanecer sua decisão.

Uma coisa que abordarei no meu livro sobre MVVM é como aproveitar o padrão para criar um aplicativo principal reutilizável. Você deve criar uma interface do usuário nativa para as várias plataformas que você segmenta (seja web, silverlight, telefone, WPF ou WinRT). Mas, na maioria das vezes, você pode encapsular a lógica que impulsiona essa interface do usuário por trás de um ViewModel.

Todos os serviços que você acessa devem ser agrupados atrás de uma interface (padrão de fachada) mais ou menos portátil entre plataformas. A interface deve mapear para a API do cliente na frente e traduzir para a API do serviço agrupado na parte traseira.

Essa estratégia ajuda a criar uma estrutura básica sólida que requer apenas uma nova interface do usuário em camadas sobre ela. Pense nisso como seu modelo de exibição sendo os músculos, seus serviços formam o esqueleto (e os órgãos). WPF / Silverlight / WinRT formam a pele.

De fato, uma coisa que aponto muito cedo no meu livro é que o MVVM não é tão novo quanto parece ser. O Dolphin Smalltalk tinha um padrão semelhante ao chamado MMVC (os dois M's eram Modelo de Aplicação e Modelo de Domínio). O ViewModel que usamos hoje é apenas uma combinação do Modelo de Aplicação e Controlador da MMVC. De fato, muitos desenvolvedores estão descobrindo que às vezes separar o ViewModel em seus dois componentes faz sentido (o controlador está sendo usado para navegar e orquestrar várias VMs, para que a VM possa permanecer alegremente inconsciente de outros componentes).

Você diz que o XAML é sólido, mas depois diz que o WPF tem um futuro questionável. A menos que esteja faltando alguma coisa, o WPF usa XAML e não vejo os dois sendo separados. Há algumas notícias que estou perdendo sobre o WPF possivelmente usando alguma outra tecnologia básica, ou sobre a Microsoft, possivelmente considerando a criação de outra maneira nova de criar interfaces de usuário? Fora isso, duvido que o WPF esteja indo a qualquer lugar, mas não seria a primeira vez que o MS obsoleta o carregamento de barcos do nosso código ...

Se você precisa de um aplicativo de interface do usuário sofisticado e o HTML5 não o adianta, e sua organização está comprometida com o sistema operacional Windows, acho que o WPF é a melhor escolha, pois é a mais recente / melhor no momento, certamente sobre winforms ...

Minha opinião é que você não deve se concentrar muito nos detalhes da implementação de seus aplicativos. Se você observar uma imagem maior, poderá isolar suas dependências tecnológicas. Ao isolar a dependência, por exemplo, de xaml / wpf / silverlight, você garante a substituição do componente / tecnologia da interface do usuário por uma tecnologia de próxima geração e, portanto, garante a continuidade mesmo em 20 anos. Isso também ajudará a dissociar os componentes do sistema e, consequentemente, o impacto de ter que executar essa substituição. (Nisso, suponho que, para fornecer continuidade, não há problema em mexer com uma solução para colocá-la em uma plataforma de próxima geração)

Uma outra maneira de fornecer isolamento dessas dependências tecnológicas é habilitar a virtualização. Se você criar seus aplicativos de maneira a poder executá-los em uma vm, poderá fazê-lo em 20 anos!