Nossa equipe está dividida e eu queria obter opiniões de terceiros.
Estamos criando um aplicativo e não podemos decidir se queremos usar o .Net WPF Desktop Application com um servidor WCF ou o aplicativo Web ASP.Net usando jQuery. Eu pensei em fazer a pergunta aqui, com algumas especificações, e ver quais seriam os prós / contras do uso de ambos os lados. Eu tenho meu próprio favorito e sinto que sou tendencioso.
Idealmente, queremos criar a versão inicial do software o mais rápido possível, depois desacelerar e levar um tempo para criar os recursos / componentes adicionais que queremos mais adiante. Acima de tudo, queremos que o software seja rápido. Os usuários passam por registros o dia inteiro e os atrasos no carregamento de registros ou na atualização de telas diminuem sua produtividade.
Detalhes de aplicação:
- Estou estimando cerca de 100 telas diferentes para a versão inicial, com planos para muitas telas adicionais sendo adicionadas posteriormente após o lançamento inicial.
- Procuramos usar a comunicação bidirecional para sistemas de lembretes e eventos
- Atualmente, é necessário oferecer suporte a cerca de 100 usuários, embora tenhamos nos dito para permitir o crescimento de até 500 usuários
- Temos vários locais
Itens a serem considerados (talvez não inicialmente em alguns casos, mas em versões futuras):
- Espaço para componentes adicionais a serem adicionados após o lançamento inicial (existem muitos deles ... talvez funcionem aqui além do aplicativo inicial)
- Navegação pelo teclado
- O desempenho é uma obrigação
- Velocidade de produção para a versão inicial
- Baixa sobrecarga de manutenção
- Suporte futuro
- Integração com softphone / scanner
Nossos desenvolvedores:
- Temos um programador que aprendeu o WPF nos últimos meses e foi ele quem sugeriu o uso do WPF para isso.
- Temos um segundo programador familiarizado com o ASP.Net e que pode ajudar com o projeto no futuro, embora ele não trabalhe muito até o lançamento inicial, pois gasta seu tempo mantendo o software atual.
- Há eu, que já trabalhei com os dois e me sinto à vontade em
- Temos uma empresa externa fazendo o gerenciamento do projeto, e eles são uma empresa ASP.Net.
- Planejamos contratar 1-2 pessoas, no entanto, precisamos saber em que direção estamos indo primeiro
Meio Ambiente:
- Os usuários gerais estão no servidor Windows 2003 com os Serviços de Terminal. Eles se conectam usando thin clients WYSE através de uma conexão RDP. A equipe de administração possui seus próprios PCs com XP ou superior. Os usuários podem especificar sua própria resolução, embora estejam limitados ao uso do IE como navegador da web.
- Outros locais se conectam à nossa rede através de uma conexão MPLS
Com base nisso, o que você escolheria e por quê?
Respostas:
Parece-me certamente um aplicativo WPF, com muita interação do usuário e potencialmente interagindo com o hardware. Você pode entregar o aplicativo via Click-Once, para que a implantação não seja um problema. Seu aplicativo WPF pode acessar um serviço WCF e fornecer os dados como binários, para que o desempenho seja excelente. Gostaria de começar a ler sobre o WPF e me familiarizar com ele o mais rápido possível.
fonte
Resposta marginal lunática: ambos. Acertar a camada de serviço, é fácil ter um cliente espesso que faz tudo (WPF) e um cliente Web rápido para fazer as coisas mais comuns (ASP.NET). Deixa a porta aberta para o cliente móvel, etc., mais adiante.
fonte
Se você possui apenas um programador que está aprendendo o WPF e está pensando em fazer sua equipe dar um salto para o WPF, por que não usar o Silverlight? Você obtém muitas das vantagens do WPF, mas ainda mantém a capacidade de deixar seu projeto como um aplicativo da web. Como você está pensando em ter um grande projeto modularizado, faria sentido usar o PRISM com WPF ou Silverlight para tornar o MVVM mais simples.
Minha equipe recentemente optou por usar o Silverlight no asp.net. Foi uma escolha fantástica para nós. Inicialmente, tínhamos apenas um desenvolvedor que conhecia qualquer silverlight. Então todos nós tivemos uma semana de aulas de treinamento que eram praticamente inúteis, mas pelo menos molhávamos os pés. No final, tivemos que contratar dois contratados para nos ajudar na criação da maior parte de nossa estrutura de interface do usuário. A maioria da nossa equipe ainda não está confiante em suas habilidades no Silverlight. Eu, o membro inicial da equipe com conhecimento do silverlight, e os dois contratados são os responsáveis pela maior parte do desenvolvimento do SL. Depois disso, temos dois membros dedicados de back-end. Eu diria que demoramos cerca de 2 meses depois de tomar a decisão de mudar para o Silverlight que realmente tínhamos algo concreto. Contudo, agora temos um produto maravilhoso que se parece muito com um aplicativo do lado do cliente que está sendo executado dentro de um navegador da web e não é instalado em nenhuma máquina localmente. O desenvolvimento foi inferior a um ano e estamos quase prontos para liberar ou candidato a primeiro release.
Algumas coisas a considerar:
WPF ou silverlight, o que você escolher, haverá uma quantia justa que seus desenvolvedores precisarão aprender.
O Silverlight pode ficar sem navegador, se necessário. Se você fizer isso, é muito fácil configurá-lo para que, se você lançar uma nova versão, o programa SL instalado no navegador se atualize automaticamente.
O Silverlight não inclui todos os controles que o WPF possui.
Minha nota final é que, se você quiser produzir código o mais rápido possível, é bastante óbvio que você deve usar o ASP.NET. Minha principal preocupação com o ASP é que, a menos que você discipline sua equipe, é fácil para um projeto do ASP.NET ficar confuso e confuso. Se você acha que conseguirá lidar com a sobrecarga inicial de se atualizar com as tecnologias, o Silverlight ou o WPF permitirá muitas possibilidades maravilhosas.
fonte
Esta parte é bastante preocupante:
O WPF não é excelente nas conexões da Área de Trabalho Remota / Thin Client. As animações não serão suaves e quaisquer imagens complexas (mesmo gradientes) atrasarão a resposta da interface do usuário para um rastreamento. A equipe de administração com máquinas XP retrô típicas também provavelmente terá problemas de desempenho com aplicativos WPF complexos (devido a pequenas quantidades de RAM e GPUs ruins).
Se você seguir a rota WPF para obter gráficos ricos, esteja preparado para hacks de desempenho de última hora quando descobrir que as máquinas de destino têm dez anos. Atenha-se a telas estáticas e use o .NET 4.0, pois o desempenho do WPF melhorou drasticamente desde o 3.5.
fonte
Tecnicamente, acredito que a combinação WPF / WCF é a melhor solução.
No entanto, não estou convencido de que seu programador WPF existente realmente tenha a experiência para este projeto. O WPF é uma grande mudança na programação de processos de pensamento da programação Winform e, portanto, você precisará pensar muito sobre se realmente possui habilidades suficientes na equipe para entregar essa rota.
fonte
Interessante. Parece incrivelmente familiar para um aplicativo que acabamos de iniciar na minha empresa (integração com telefone sip e scanner e tudo).
Escolhemos o silverlight com foco na SOA, para que um aplicativo WPF pudesse ser feito posteriormente, se necessário.
Estamos usando o MEF na camada de serviço e construindo pontos de extensão (interfaces de plug-in que descrevem certos pontos nos quais planejamos extensibilidade ou integração com outros sistemas)
Não é um problema.
Que tipo de performance? Desempenho percebido (snappy-ness) ou desempenho de processamento de números? O último pode ser um problema com um aplicativo web / silverlight. Para o primeiro, nosso aplicativo passa por muitos registros, como o seu, mas podemos prever e buscar previamente os registros enquanto os usuários estão trabalhando nos atuais. Os tempos de 'carregamento' são zero para essa seção do nosso aplicativo.
Depende do conjunto de habilidades. Mas, realisticamente, todo mundo sempre quer chegar ao mercado o mais rápido possível, por isso não é um argumento.
Assim como a velocidade de produção, também não é um argumento e vai se resumir a práticas de design e codificação. Se você está falando em termos de manutenção de hardware, convém usar um aplicativo em nuvem.
Não tenho certeza do que isso significa.
O Silverlight 4 agora permite acesso à webcam / microfone (esperamos fazer videoconferência entre aplicativos e integração com goles); portanto, se você estiver usando um servidor de telefone, poderá escrever um. Não conheço nenhum existente, mas isso pode ajudar.
Caso contrário, talvez você precise fazer alguns hackers feios (não faça mais uma referência ao (s) artigo (s), desculpe) ou não terá outra opção a não ser ter um aplicativo WPF que possa interagir com o sistema de arquivos. O SL4 pode sair do navegador, mas pode acessar apenas determinadas partes do sistema de arquivos. Provavelmente, nenhuma delas será a parte que você precisa para interagir com um telefone SIP.
Você quer dizer scanner de documentos? Não tenho certeza sobre isso. Estamos usando scanners de mão / código de barras, e eles operam como qualquer outro dispositivo de entrada e não são um problema.
fonte
você precisa de um aplicativo altamente responsivo para que as pessoas usem o dia inteiro? use WPF; você achará mais fácil reutilizar componentes da GUI no WPF sobre ASP / MVC também (IMHO)
sim, jquery et al são ótimos, o silverlight é legal, mas os aplicativos de desktop ainda são mais eficientes
para o back-end, o WCF é bom
fonte
Terei de recomendar que você use o WCF para sua camada de serviço devido à escalabilidade e segurança. Para a camada de apresentação, você pode usar o Silverlight ou o ASP.NET, o Silverlight é como o Flash, mas é difícil entender e ter uma alta curva de aprendizado no início, principalmente ao trabalhar com dados. O ASP.NET é mais fácil de usar, mas você precisará de muitos ajustes e javascript para usá-lo com eficiência.
fonte