Prism with ASP.NET

Question

My company is looking into ASP.NET and Prism. We are wondering how much code reuse we can get between the two options.

As I see it Prism has these "parts":

• Shell (Bootstrapper and such)
• Modules
• Services (not web-services)
• Regions
• Loosely Coupled Events (IEventAggregator)
• Unity (though really this is a standalone product)

As I look at this, the only part that absolutely must be used with Silverlight/WPF is Regions.

The shell may be a bit tricky, but I think It could be done in an ASP.NET app. I also think that Modules (non-Region offering modules) should also be doable. Using IEventAggregator and Unity should be easy.

The only problem I have is that I am not really experienced in ASP.NET programming, so I am not sure of my assumptions. I would love some feed back from someone who is familiar with both Prism and ASP.NET before the discussion on this goes into full swing (here at my company), .

Basically, I want to make Prism modules that will run web-services and business logic. I then want to take these modules and (re)use them in ASP.NET apps and WPF/Silverlight Prism Modules (via Regions).

Am I charting a difficult journey by trying to merge these two systems?

Answer 1

The problem you're going to run into is the different lifetime styles between client apps and web apps.

Web apps are basically stateless - the object graph is built up, the request is satisfied, and then everything is thrown away. Web apps have to be written assuming that many different users are hitting it at the same time.

Client apps, on the other hand, start up, set up their environment, and then keep everything around in memory. Also, a client app instance will have one user, not many. The shell and the EventAggregator in particular rely on everything sticking around in memory, even across requests, and don't differentiate between who is working (because in that world, there's only ever one).

I think you can get most of the goodness you want just by hooking up a DI container at the right place and writing a bit of bootstrapping code to pull in code at runtime.

Answer 2

If code reuse is a big concern (which it should be), then I would look at your project lifetime requirements. Do you need this code to survive a few years, 5 years, 10 years? More? Obviously most big projects want their code to survive as long as possible with as little maintenance (or rewrite) as possible.

The reason I bring this up is that if you write your code modules using Prism or ASP.NET, then you're tying up your (potentially) reusable code into that specific technology, which may or may not be used in 5+ years. This is coupling your long-term code with relatively short-term technology. What happens in several years when the "next big thing" is released, and you'd like to migrate your project to it? If you're coupled to Prism or the current ASP.NET, you may find it fiscally difficult/impossible to switch technologies.

You're better off abstracting your application logic and flow into a top-level, technology-agnostic structure that can be interfaced with Prism and/or ASP.NET. This idea of decoupling is one of the main reasons that IoC/DI containers (like Unity) have become so popular of late. It also makes unit testing a whole lot easier.

In essence, using some application infrastructure (such as N-tier) you'd encapsulate your business logic and data access, while abstracting your user-interface in such a way that it can be reused. Model-View-Presenter also demonstrates abstracting your UI for maximum reuse and unit testing.

An N-tier application infrastructure also shines when you're looking at distributed computing - what happens when you want to run your Prism application on the client's machine, but you want to host your application's data (i.e. a SQL Server Database, for example) on the server? If your client's machine is on your network, that's fine - you can give them a connection string to the server, no problem. But if you plan on accessing your data across the Internet, then you need to abstract your application's data layer and provide methods to (securely) retrieve the data across the Internet.

Answer 3

I upvoted Chris' answer, because it is 100% correct with vanilla asp.net. However, with a bit of creativity, you may be able to leverage Knockoutjs to get closer to your goal.

Answer 4

I think you're heading down a world of hurt. I've dug into the Prism code and it's not pretty and it's closely tied to WPF/Silverlight. The models are very different and the thought of sharing code sounds great, but I bet will be next to impossible.