MVVM, SOA, and AJAX (oh my?)

I'm researching architecture for what will be a large and very sophisticated system. Our v1.0 goal is to build a single app with a modern n-tier archiectu开发者_如何学Gore. We will likely build the UI with Silverlight, and we will likely use an MVVM pattern.

However, in the future, we would like to offer up some of the application logic as services (for value-added ASPX apps, custom extensions, supporting iPhone/Windows Phone apps, etc). (ideally, whatever UI technology we use will harness the same server-side logic as our original app)

I've been reading about using MVVM in conjunction with WPF and Silverlight. It looks great, but it also looks like your ViewModel classes are client-side, and platform-specific (eg, written in .Net/Silverlight).

Suppose I build a large Silverlight/MVVM app as v1, and then with v2, I want to expose a subset of the functionality as a traditional aspx web site. Do I have to re-write all of the ViewModels in JavaScript? Is there some guidance for building my MVVM pattern with an eye for keeping all of the most important logic in the server-side code?

I would say Yes, you'll have to re-write all of the ViewModels.

Moreover, for your plain old HTML version you'll probably go with ASP.NET MVC, which is a bit different approach. Moreover, HTML version tends to look different, simpler than RIA version, so you'll probably need different ViewModels anyway.

As for native iPhone version, you can probably reuse the same web services, the Silverlight version does. However, UI must be completely rewritten.

Exposing your data via WCF Data Services (ODATA) will make your data access in any technology stack much easier (even easier than custom REST).

Not a full answer to your question, but on the client side you may be able to re-use your code in spirit/structure with Knockout, an MVVM library for JavaScript: http://knockoutjs.com/

I'd say it depends on how you write your view models. If they are simply classes with properties you should be able to expose them to an ASP.NET MVC application. However if within your view models you are creating/consuming Silverlight controls then of course they will need a rewrite. Perhaps you could construct all of your view models in a way that they have a base portion that is consumable to both ASP.NET MVC as well as Silverlight and then have a specific view model that is extending the base and adding the technology specific portions of the VM's. The other thing you need to look into is that Silverlight has Silverlight specific class files. I'm not if there are restrictions on how these can be consumed by ASP.NET, the do however restrict what portions of .NET are available to you.

I just wonder if you're focused on the front-end just a little too much? It's not that your concerns are "bad" or "wrong", I just think you might be putting the cart before the horse.

I'd start by ensuring your underlying Business Logic is really sound, then move on to the services / API's that expose them. If this based is good, then it'll be easier to build the next layers.

The more reuse you can get at this level the less you'll have to duplicate / re-write in different implementations on the next layer up.