Oct 20, 2010 at 8:34 AM
Edited Oct 20, 2010 at 9:29 AM
Hi to all,
I've been experimenting with Prism 2.2 for SL4 according to this example by Jeremy Likness:
I noticed that in this example - and many others for that matter - that for each composite View there's an associated Module created as a separate class. Assuming we're implementing MVVM, that means each 'View' has the following files associated with it:
- the XAML (Orders.xaml)
- the XAML code-behind (Orders.xaml.cs)
- the ViewModel (OrdersViewModel.cs)
- the PRISM Module that implements IModule (OrdersModule.cs)
I'm aware that the Module class doesn't have to be an actual file and be written / included somewhere else, but for complexity's sake and to adhere to what the various PRISM examples are showing, let's assume that the Module is in a separate file.
I dunno, but that seems a lot of files for 1 View. Sure it's a small price to pay for the composition, decoupling and good segregation that PRISM and MVVM offer but here's where this thread's title comes into play: Why not let XAML code-behind implement
Theoretically it's feasible - it's just an interface implementation - but it doesn't show anything. The modules load correctly, but nothing is rendered. Another downside is that the regionManager instance would get instantiated twice, but that's easily solvable:
public Orders(IRegionManager r)
if (_regionManager == null)
_regionManager = r;
I know it's preferable to keep the view's code-behind as 'clean' as possible, but that can also be solved by making all views inherit a main app view where all this IModule management can reside, no? (Please correct me if I'm wrong)
Also, IF it is feasible to have the XAML code-behind as the Module itself, what needs to be done in order for the module to render and actually show? Or perhaps it should and I'm doing something wrong...
So if it's feasible, are there any 'bad practice' warnings anyone can shed some light on that I'm not aware of?
Thanks in advance.