views:

210

answers:

3

We are currently designing a business application that has two primary requirements for it's UI:

1) run on the Desktop (WPF) for enterprise users to provide a rich user interface, interoperate with other applications, access the filesystem, work offline, work with special local hardware, etc.

2) run on ASP.NET/Ajax to provide several components of this application to customers (internet). Unfortunately Silverlight is not (yet) an option.

Even though we don't have to make the full application available on the web, some of these components are fairly complex and we would like to share as much UI code as possible with the WPF implementation.

What options do we have to reach this goal? Is there a pattern that works well with both technologies?

Update:

Thanks for the answers even though they don't include the one I was looking for! :)

I don't think UI generators are a good option. Like Eduardo pointed out you will probably end up with problems in both worlds. I will check out Sculpture though.

+4  A: 

I've been thinking along these lines for a while now, and I've yet to come up with a great answer. That being said, here are some of my thoughts:

If you used some variation of the various MVP/MVC/MVVM UI methodologies and you were very disciplined in this approach (i.e. not mixing presentation stuff with behavior stuff), you'd probably be farther down the road.

You might consider investigating the various DSL toolkits that have cropped up, the idea being to create a simple "language" to describe your UI at a high level and generate a representation of that UI in WPF/ASPX.

Also, I ran across this recently. I have no idea how good it is. I'm planning to take a closer look when I get the chance.

Daniel Pratt
Thanks, I've downloaded Sculpture and will take a look at it!
chris
Sculpture is not what I want to use for any application so I'll stick with MVVM and MVC, thanks!
chris
+2  A: 

Good luck!

The unfortunate truth is that Asp.net/ajax (the web in general for that matter) and WPF (and heck, let's throw WinForms in there for good measure) have very different User Interface models and what works well for one is not necessarily going to work well for another. That's not to say that you can't share logic between applications written for either technology, but, I'll make a stretch here, your UI logic is not going to be in that category.

I've been using a variation of MVVM for WPF and ASP.Net MVC most recently and I'd say they are very good fits for the technology at hand. However, while they are very similar, they have their differences and I'm not sure you could write an abstraction layer (in any decent amount of time) that could take advantage of the great features in both technologies.

Ultimately, I'd say that your best bet is to follow some SOA patterns and extract as much of your business and data access logic into common libraries as possible. Then, write separate user interfaces in WPF and Asp.net to take advantage of those common libraries. This is the approach that my company is taking at the moment, and it's working like a charm.

It may seem daunting to write your UI logic twice (once for asp.net and once for wpf), but I think it's worth it so that your code can fit the patterns and practices that best fit those technologies.

As an aside, even though Silverlight is not an option, have you considered XBAP?

dustyburwell
+1  A: 

If a former job we did something similar. As Daniel Pratt says, we describe our interfaces in XML and then a render will create the form, report or whatever we decided to create.

We have to provide a Javascript function to do some UI validations in the HTML render, and a call to a java function in the Swing render.

Beware that you may end with imperfect apps in both worlds.

Eduardo Molteni