One ObjectContext for ViewModel?

Topics: Bootstrappers & IoC, Framework Services
Mar 22, 2012 at 10:14 AM

I'm learning this mvvm framework, and I find it very nice.

I'm a newbie on this mvvm world, and I have a question:
I'm building a wpf application, with List\Detail scenarios using Entity Framework, and I would like to use one objectContext for each viewModel, disposing it in the "OnDeactivate" function (when close is true).
So I created one interface called IMainServices where there are methods to retrieve or save objects and I created its implementation (called MainServices) where inside I created an object context.
So, in each view model, there will be a reference to IMainServices.

But if I register the IMainServices in the BootStrapper, I see that the MainService "will become a Singleton", and in each viewmodel will be injected the same instance of MainService and so I can't make the dispose.

A solution could be to instantiate the MainService manually inside each viewModel, but I think that it isn't a good practice...isn't it?
So, which solution should I use?

Thank you

Mar 22, 2012 at 10:41 AM

I suppose that your best option would be create MainServices as a singleton, and find a way to notify the service that the context should be destroyed.

In other terms, even if the IMainService implementation is a singleton, there is no reason preventing your from creating a context-dispose strategy.

As an example, you could acquire a token every time you need the context (e.g. view-model Initialize), realease it when needed (e.g view-model Deactivate) and have the MainService react to the token deactivation, so that once the last token is deactivated, the context gets destroyed. As you can see, this way you get a centralized service, as a singleton, but every view-model is able to influence the lifetime of the context through some instance-specific tokens.

Mar 22, 2012 at 11:04 AM

If I understood well:
there will be only one MainService instance, but the MainService doesn't have a context inside.

Instead It will have a Dictionary<token, context> called _dictTokens inside.
There will be the AddToken(object) function that will add an item to the dictionary using the object as token: _dictTokens.Add(object, new Context)
There will be the RemoveToken(object) function that will remove an item from the dictionary, making also the dispose: _dictTokens(object).Dispose(), _dicttokens.remove(object)

In the Initialize of view model, I will cal the MainService.AddToken(this) and in the Deactivation I will call the MainService.RemoveToken(this)

I'm not sure I have understood well, anyway in thsi case, when I have to retrieve some objects, and so call a MainService function, I have to always pass in the method the token to use... is this right?

Mar 22, 2012 at 11:30 AM

Yes, more or less this is my suggestion.

Regarding your last question, it depends on how you design your main service. Your token could be responsible to expose the functions you are currently associating to the MainService, for example. This way the service is only responible for managing contextes and their lifecycle, while tokens are per-instance-'proxies' of the MainService used by view-models.

Mar 22, 2012 at 1:08 PM

Now my IMainServices interface has two only methods:

 IWorkerService AddToken(object item);

 void RemoveToken(object item);


I have the new interface IWorkService (that is the token) where there the methods for retrieve and save the object from database.
this interface must implement IDisposable.


in the MainServices implementation there is a dictionary of type <object, IWorkerService>, and in the RemoveToken, I call the dispose of the workerservice.
In the AddToken, I create a new instance of WorkerService and I return it.

So in the ViewModel, on the initialize I can do:
_workerService = _mainService.AddToken(this);  (_mainService is retrieve with Ioc.Get)

and in the OnDeactivate:
if (close)


Is this what you intend?

thank you for your help

Mar 22, 2012 at 1:31 PM

I would probably use the following interface

public interface IMainService
       IWorkerServiceToken GetToken(object item);

and, depending on the IWorkerServiceToken interface, you could either call the Dispose method on the token, or provide a Release method to do the clean-up (note that in these cases, the main service should keep track of disposal/release, to clean-up the internal register).

If you prefer to let the main service create/destroy your tokens directly, I would go for an interface like

public interface IMainService
       IWorkerServiceToken GetToken(object item);
       void ReleaseToken(object item);

But it is just a matter of personal tastes...

Mar 22, 2012 at 2:20 PM

I think I will use this interface to make the things easier:

 public interface IMainService
       IWorkerServiceToken GetToken();

I don't know if I'm wrong, but I think that I can remove the item parameter in the GetToken, because my WorkerService implements Disposable, and I can easily manage it inside the ViewModel: with the GetToken I will get the WorkerService in the Initialize of ViewModel, and in the Deactivating I can call the dispose of the WorkerService (I will use a base class inheriting from the Screen class).

is this right?

Mar 22, 2012 at 2:41 PM

Yes, I suppose you can simply go with it. :)

Mar 22, 2012 at 3:01 PM

thank you very much for your support.