A estrutura e o jQuery do MS MVC são adequados para um aplicativo de longa duração?

Question

Estou trabalhando em um aplicativo baseado na Web que se destina a ter pelo menos uma vida útil de 6 anos. Depois que o aplicativo é entregue, é provável que ele não seja modificado durante esse período.

Estamos pensando em usar a estrutura e o jQuery do ASP.NET MVC, mas estou me perguntando se essa é uma boa escolha. O cliente provavelmente não vai querer gastar mais tempo e dinheiro no caminho, porque o JavaScript, os padrões do navegador etc. mudaram.

Qual é a melhor opção para minimizar as chances de o aplicativo exigir manutenção nos próximos 6 anos?

Answer 1

O cliente provavelmente não vai querer gastar mais tempo e dinheiro no caminho, porque o JavaScript, os padrões do navegador etc. mudaram.

Ela é, ou não é? Você pode convencê -la de que o mundo ao redor dela continua se movendo, e ela vai precisar Para atualizar seu aplicativo para trabalhar com as principais plataformas do futuro?

Suponho que este seja um aplicativo intranet, não um aplicativo público (internet face). Porque se for intranet, acho que 6 anos não são realistas, mas o modo de falha provavelmente será bastante benigno. Mas internet, 6 anos e nenhuma atualização de segurança para o próprio aplicativo - de jeito nenhum, eu não participaria disso para evitar danificar minha reputação profissional.

Eu tentaria muito vender um retentor (taxa de manutenção de software) para manter o aplicativo atualizado. E com isso, um bom documento legal descrevendo claramente o que o cliente recebe pela taxa (ou seja, compatibilidade e correções de segurança, sem novos recursos). A manutenção de software normalmente não é tão difícil de vender se você também fizer a hospedagem.

Por uma questão de argumento, assumindo que o pedido seja 'congelado' por 6 anos:

Eu poderia absolutamente não Use JavaScript em qualquer coisa que deve durar mais de 4 gerações do navegador. Eu acho que o jQuery é ótimo, mas ... de jeito nenhum, os motores JavaScript estão mudando muito rápido. Para a produção, eu faria só:

• HTML 4.01 Strict & CSS 2 (Eu estava pensando em XHTML 1.0 Strict, que é essencialmente HTML 4.01 Strict alterado para estar em conformidade com as regras XML. Mas o HTML 4.01 tem a maior base instalada, e não sou fã de XML. É uma decisão.)
• PNG & GIF.

Com relação a manter as coisas estáticas, Esta saída simples é provavelmente a maior vitória.

Para o ambiente do servidor, Eu tentaria especificar o Windows 2008 R2; .NET 4.0 e ASP.NET MVC 2 e uma configuração do servidor 'quase congelada' (apenas atualizações de segurança). Windows 2008 R2 deveria ter um suporte estendido para torno 10 anos a partir de agora. A geração anterior (Win 2008, .NET 3.5SP1 e MVC 1.0) também funcionaria; Mas o ASP.NET MVC 2 parece tão bom, então eu prefiro usá -lo para o meu FunFactor pessoal.

Grandes projetos de código aberto com um bom histórico de 'estar lá' também ficariam bem - Nibernate, Nunit, StructureMap etc.

Ah, e boa chamada usando asp.net. A Microsoft ainda é boa em manter a compatibilidade com versões anteriores e as correções de segurança de backport. Asp.net e Java são os dois únicos ambientes que eu consideraria para algo assim.

Answer 2

Você provavelmente não terá que se preocupar com isso. Existe um investimento tão grande em trabalhar com o JQuery de várias grandes empresas que duvido que você encontre esses tipos de questões. A Web provavelmente sempre estará condenada a permanecer compatível com o atraso (e isso significa que as coisas que saíram há 10 anos atrás), por isso suspeito que seu aplicativo baseado em jQuery deve estar bem. Se você estiver bem com o IE7/8, o último Firefox e o Safari, você deve estar bem. Ou seja, se não for suficiente, provavelmente provavelmente nenhuma outra solução baseada na Web também.

Mas eu definitivamente recomendo o uso do jQuery para esconder você de muitos dos problemas específicos do navegador em termos de interação JavaScript. Quanto ao ASP.NET MVC, novamente é uma plataforma bastante sólida que acho que muitas empresas continuarão apoiando nos próximos anos.

Answer 3

Para o jQuery, apenas não se preocupe, como disse BobbyShotoe.

Para o ASP.NET MVC, ele não vai morrer em breve; No entanto, uma vez que é uma tecnologia muito jovem e provavelmente muda com frequência nos primeiros lançamentos, podem ser esperados problemas de manutenção.

O mesmo costumava acontecer com os trilhos: um aplicativo escrito com trilhos 1.x precisava de algumas alterações para funcionar TH Rails 2.x.

Isso pode ser um problema ou não: um aplicativo escrito com Rails 1.x continuará trabalhando com o Rails 1.x, e um aplicativo escrito com MVC 1 continuará trabalhando com o MVC 1.

Eu acho que ainda é muito cedo para dizer quanto MVC 2 diferirá do MVC 1: MVC 2 Visualizar 2, mas deve -se observar que muitas classes, métodos, interfaces etc. alteraram o nome e o comportamento várias vezes entre o MVC 1 RC1, MVC1 RC2 etc.

Por outro lado, se o seu aplicativo for complexo o suficiente, o uso do MVC ainda pode ser a escolha certa, mesmo considerando o esforço extra necessário para atualizar para os lançamentos mais recentes (o que geralmente não é tão grande): um aplicativo MVC é mais sustentável (em minha opinião).

Uma consideração final: observe que 6 anos são muito tempo no mundo da web selvagem, por isso não é possível dizer com antecedência o que mudará e o que não será.