CODEWITHSUNDEEP
.netwpfmvvmprism
NuclearProgrammer
NuclearProgrammer

Reputation: 926

Proper use of PRISM regions outside of the Shell

I'm part of a team that rewriting a 20+ year old PowerBuilder 2.0 application. The application is massive, and a clean cutover to the new system is not possible. We have been forced to integrate the two systems as we slowly replace old functionality with new .Net code.

Basically, our new application is written using WPF/MVVM. We wrote an COM-visible "adapter" class that the PowerBuilder code uses to open a .Net transaction (view). The adapter has a OpenTransaction(string transactionName) that the old code calls, and uses reflection to find the view with the corrisponding name. User navigation takes place entirely within the old code.

Each of our .Net transactions inherit from ViewBase which inherits from UserControl. Eventually (when we have replaced all of the legacy code), we intend to have all transactions open in a tab-control in a single Shell with a modal navigation window. For now though, each transaction opens in its own window with a single "content" region.

We've just started exploring using PRISM, and my question is, other than to subdivide our Shell and define the general layout of our application's main userinterface (which we really can't do right now), is there any reason to use PRISM regions and/or navigation?

One of our team members is convinced that we should use regions to subdivide our views. For example, we have a "MaintainColors" transaction (with a "MaintainColorsViewModel") within this transaction, we have

He argues that these should both be PRISM regions and should be implemented as DataTemplates for our MaintainColorsViewModel and that we should have a "generic" Maintain transaction. His point is that we could use the same Maintain transaction for diffrent types of items by swapping out the ViewModel and loading the appropriate DataTemplates.

My argument is that these "templates" would not be reusable and are tied to specific types of ViewModels. We would still have to define what our "Select" and "Edit" regions would look like (so we're not reducing code) and its not like we are ever going to use the "EditIndividuals" template with the "SelectColor" template.

Is there something that I am missing here?

Upvotes: 1

Views: 226

Answers (1)

user5420778
user5420778

Reputation:

That's a lot to take in. I'm not sure I have a solid understanding, but I did see the part about how all navigation is handled by the old system. So that tells me that until you can pull that out, you can't use Prism navigation because it relies on Regions to place XAML views into.

I would never use implicit DataTemplates base on ViewModel types. Not only is that a maintenance and debugging nightmare, but it is a performance hog too. WPF perf already sucks, no need to make it worse by using implicit DataTemplates for entire Views. Not to mention that Prism doesn't support Regions inside of DataTemplates by default (they aren't attached to the visual tree).

Use Prism where it makes sense. As the system is slowly rewritten, you can take advantage of more advanced Prism features such as modularity, and Regions.

Upvotes: 0

Related Questions