More on the View Injection Quickstart

Topics: Prism v1, Prism v2 - Silverlight 2, Prism v2 - Silverlight 3, Prism v2 - WPF 3.5
Sep 18, 2009 at 2:16 PM

In reviewing the View Injection quickstart, the projectlist view is injected into the employee details region.  The coordination between the employee module and the projectlist module is handled in the EmployeeController class. 


here's the snippet


 public virtual void OnEmployeeSelected(BusinessEntities.Employee employee)
            IRegion detailsRegion = regionManager.Regions[RegionNames.DetailsRegion];
            object existingView = detailsRegion.GetView(employee.EmployeeId.ToString(CultureInfo.InvariantCulture));

            if (existingView == null)
                IProjectsListPresenter projectsListPresenter = this.container.Resolve<IProjectsListPresenter>();

                IEmployeesDetailsPresenter detailsPresenter = this.container.Resolve<IEmployeesDetailsPresenter>();

                IRegionManager detailsRegionManager = detailsRegion.Add(detailsPresenter.View, employee.EmployeeId.ToString(CultureInfo.InvariantCulture), true);
                IRegion region = detailsRegionManager.Regions[RegionNames.TabRegion];
                region.Add(projectsListPresenter.View, "CurrentProjectsView");

The fact the Employee Controller is referencing the IProjectsListPresenter interface represents tighter coupling between the modules.  Should there be a controller that sides outside the employee and projectlist modules, that can respond to a public event from the employeeList presenter when an employee is selected?


Sorry if this is off-base, I'm trying to wrap my brain around the scoping and levels of control.


Sep 18, 2009 at 3:07 PM

You bring up a good point - the team discussion around this one would be coupling versus complexity.   If the team doesn't have, or develop, good commenting/logging habits an application decoupled in the manner your suggesting could be harder to read/debug/maintain.  On the other hand the tight coupling could hinder reusability particularly in an enterprise environment. 

Where I am a proponent for separation of concerns and the separated presentation pattern I, like most, don't look forward to having to sift through numerous projects and classes to figure out how everything is wired up; particularly if I am new to the project or havn't touched it for a year.  Sometimes we (the team) choose to sacrifice coupling for this reason, particularly for a small project.   The key is finding balance with the team which revolves around many factors - at a high level I like the above because of the KISS principal but at a higher level I would prefer your method because I would want to be able to reuse the employee view in other applications without being forced to pull in the project list.

The important part would be that the team understand the domain and long range goals so that they could debate and come up with the best plan for the project at hand.



Sep 18, 2009 at 5:09 PM

I think I'm starting to understand the argument for the way the controller is written in the Quickstart.  The Project module is a constituent module to the Employee.  The Project module, on its face, would not subsist on its own.  Therefore the reference to the Project module from within the Employee module makes sense.  Where I see modules living on their own is when they can be used entirely on their own.  Now, here's a question.  Taking the Modularity Quickstart as an example, if you wanted each module the ability to inject a view into a region on the right from a click on the left, would you manage that in a module above the modules loaded into the left?  I'm looking the develop an app that has a tree on the left, and opens view on the right.


Sep 18, 2009 at 5:32 PM

I really liked Guillermo's approach to the toolbar in this thread   I'm not familiar with the Modularity Quickstart, however If I were using a treeview for navigation in the manner you are suggesting I would probably want to apply the same reusability concepts that he did for the Toolbar; designing it a manner where it could be in a standalone module and reused for multiple applications.

Sep 18, 2009 at 7:07 PM

That is how I do it in my SCSF/CAB app.  I have an all encompassing service that manages the treeview on the left.  Thanks,.