Are the MS MVC framework and jQuery suitable for a long-lived application?_问答_开发者

I'm working on a web-based application that is intended to have at least a 6 year lifetime. Once the application is delivered, chances are that it won't be modified during that time frame.

We're considering using the asp.net MVC framework and jQuery, but I'm wondering if that's a good choice. The customer is probably not going to want to spend additional time and money down the road because javascrip开发者_如何学JAVAt, browser standards, etc have changed.

What's the best option to minimize the chances that the application would require maintenance over the next 6 years?

You probably won't have to worry about that. There is such a huge investment in working with JQuery from several big enterprises that I doubt you will run into those kinds of issues. The web will probably always be doomed to staying backward compatible (and that means with stuff that came out 10 years ago today) so I suspect your JQuery based application should be fine. If you get it going fine with IE7/8, latest Firefox, and Safari, you should be all right. That is, if those won't suffice then probably no other Web based solution will either.

But I definitely recommend using JQuery to hide you from many of the browser specific issues in terms of Javascript interaction. As far as ASP.NET MVC, again it is a pretty solid platform that I think many enterprise will continue to support for years to come.

customer is probably not going to want to spend additional time and money down the road because javascript, browser standards, etc have changed.

Is she, or is she not? Can you persuade her that the world around her keeps moving, and she will need to update her application to work with the major platforms of future?

I assume this is an Intranet application, not a public (Internet facing) application. Because if it's Intranet I think 6 years is unrealistic, but the failure mode is likely to be fairly benign. But Internet, 6 years and no security updates to the application itself -- no way, I would not participate in that to avoid damaging my professional reputation.

I would try hard to sell a retainer (software maintenance fee) for keeping the application current. And with this, a good legal document clearly outlining what the customer gets for the fee (i.e. compatibility and security fixes, no new features). Software Maintenance is typically not that hard to sell if you do the hosting as well.

For the sake of argument, assuming the application shall be 'frozen' for 6 years:

I would absolutely not use Javascript on anything that is supposed to last 4+ browser generations. I think jQuery is great, but ... no way, Javascript engines are changing much too fast. For output, I would stick to only:

HTML 4.01 Strict & CSS 2 (I was thinking about XHTML 1.0 Strict, which is essentially HTML 4.01 Strict changed to conform with XML rules. But HTML 4.01 has the largest installed base, and I'm no fan of XML. It's a judgment call.)
PNG & GIF.

With regards to keeping thing static, this simple output is probably the single biggest win.

For the server environment, I would try to specify Windows 2008 R2; .NET 4.0 and ASP.NET MVC 2, and a 'near-frozen' server configuration (i.e. security updates only). Windows 2008 R2 should have extended support for around 10 years from now. The previous generation (Win 2008, .NET 3.5SP1 and MVC 1.0) would also work; but ASP.NET MVC 2 is looking soo nice, so I'd prefer to use that for my personal funfactor.

Large open source projects with a good track record of 'being there' would be fine too -- nHibernate, nUnit, StructureMap et cetera.

Oh, and good call on using ASP.NET. Microsoft is still good at keeping backwards compatibility and backporting security fixes. ASP.NET and Java are the two only environments I'd consider for something like this.

For jquery, just don't worry, as bobbyshaftoe said.

For ASP.NET MVC, it isn't going to die soon; nontheless, since it's a very young technology and likely to change frequently in the first releases, maintenance problems may be expected.

The same used to happen with rails: an app written with rails 1.x needed some changes to work th rails 2.x.

This may be a problem or not: an app written with rails 1.x will keep working with rails 1.x, and an app written with MVC 1 will keep working with MVC 1.

I think that it's still too early to say how much MVC 2 will differ from MVC 1: MVC 2 Preview 2 is out, but it must be remarked that many many classes, methods, interfaces etc. changed name and behaviour several times between MVC 1 RC1, MVC1 RC2 etc.

On the other hand, if your app is complex enough, using MVC may still be the right choice, even considering the extra effort needed to update to the newer releases (which is usually not so big): an MVC app is more maintainable (in my opinion).

A final consideration: please note that 6 years are a very long time in the wild web world, so it's not possible to say in advance what will change and what will not.