Home/ Questions/Q 3481058
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T10:24:37+00:00

My company is looking into ASP.NET and Prism. We are wondering how much code

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0