tags:

views:

22

answers:

1

I am designing an application (Silverllight or WPF, still debating) but I am stuck at a design issue and was if wondering you could provide your opinion on it....

Here's the scenario. This is an Employee management application for HR. Once the application is ready, HR may ask for more features to be added(which most of the time means, more data). Say there is an employee form that saves employee record in the database.The employee form has an associated EmployeeViewModel that it communicates with. The EmployeeViewModel uses Entity framework to persist its data in the database.

Now if the HR wants to add a new set of fields say "Spouse Information", I plan to provide a plug-in that HR can simply add to the form when available. This plug-in, SpouseInfo is sort of a usercontrol with a view model of its own.

The problem is who owns the ViewModel here.

a. Do I make SpouseInfo completely independant. Whenever Employee form is Saved or loaded, SpouseInfo calls its view model and loads or saves the data. In this case before it can save or load the data, It would need the EmployeeId from the Parent form before the data can be saved (which means, let the Employee form save the data first and then pass the Employee Id to SpouseInfo)

Or

b. The Employee form owns the ViewModel for SpouseInfo. That being the "parent entity" it is responsible for loading and saving the "Child Entity" i.e. SpouseInfo viewModel.

Thanks, A

+1  A: 

This is really a design choice. The fact that you are using MEF doesn't mean you don't have to decide what "ownership" makes the most sense for your application, and which components should be responsible for others.

That being said, I would probably make the "SpouseInfo" information conform to a known interface, and use that interface (loaded via MEF) from the main Employee's View/ViewModel. This would allow any injected control that was an employee dependency to be loaded at runtime, something like

public interface IEmployeeDependant
{
     FrameworkElement View;
     IPersistWithParentID ViewModel;
}

If you imported that via MEF, you could handle layout easily enough, and call into the VM directly with the correct required information (EmployeeId, probably) to persist the "sub" ViewModel.

Reed Copsey
Thanks for the reply Reed. I agree how I handle this is purely a design choice and since I am in the design mode at this stage, I just want to make sure I do it the most efficient way. Your design suggestion makes good sense. I will very likely go with something like this. Thanks.
Ankur Anand