C# MVVM – How to Implement a General Method Across Several View Models

Architecturecmvvmsoftware

Currently I have implemented a method in to a model to take a screen shot like so E.G.

Interface

public interface ICapture {
 void CaptureMethod();
}

This is the model that implements that interface

public class CaptureModel : ICapture {
    void CaptureMethod(){ //implement the code to take screen shot }
}

Now I want to execute a screen shot on one or multiple view models, so I would need to instantiate the and call the function like so.

public ViewModel(){
 void TakeScreenShotMethodOrCommandDontCare(){
   ICapture captureClass = new CaptureClass();
   captureClass.captureMethod
  }
}

Which just feels WRONG having to instantiate an instance of an object in order to call a function which will be taking a screenshot.

I suppose i could go in the view model and have capture screenshot method but that would lead to code duplication across all view models with that feature.

Maybe a static utility class but surely that would be expensive on the app.

I feel if I had an interface that was implemented by a base class then my view model could inherit from that base class and implement the base implementation on any view model I desire.

So to sum up my question, if you wanted to implement a method that captures screen shots and you like mvvm then where would you implement?

Best Answer

Your code should look like this:

public class CaptureViewModel 
{
    ICapture captureService
    public CaptureViewModel(ICapture captureService) 
    {
        this.captureService = captureService
    }

    //bind this to the View
    public void TakeScreenShotCommand()
    {
        this.captureService.CaptureShot();
    }
}

The ICapture implementation is Instantiated in the DI container with the desired lifecycle and injected into the ViewModel. Allowing you to reuse the code across all ViewModels

captureService is implemented in a library class somewhere.

public class CaptureService : ICapture
{
     public void CaptureShot() {...implementation code here }
}

your DI Container or startup class looks like

public void Main()
{
    var container = new DiContainerOfChoice();
    container.Register<ICapture>(new CaptureService());

    MainView = container.Resolve<MyView>();
    // view requires ViewModel which requires CaptureService, DI sorts it all out for you

    //poor mans DI
    var cs = new CaptureService(); //keep hold of this to pass into other view models
    MainView = new View(new Viewmodel(cs));
}

Related Solutions

C# – How to make creating viewmodels at runtime less painful

The issue of dependencies when initiating a new view model can be handled with IOC.

public class MyCustomViewModel{
  private readonly IShoppingCartWebService _cartService;

  private readonly ITimeService _timeService;

  public ProductDTO ProductDTO { get; set; }

  public ProductDetailsViewModel(IShoppingCartWebService cartService, ITimeService timeService){
    _cartService = cartService;
    _timeService = timeService;
  }
}

When setting up the container...

Container.Register<IShoppingCartWebService,ShoppingCartWebSerivce>().As.Singleton();
Container.Register<ITimeService,TimeService>().As.Singleton();
Container.Register<ProductDetailsViewModel>();

When you need your view model:

var viewmodel = Container.Resolve<ProductDetailsViewModel>();
viewmodel.ProductDTO = myProductDTO;

When utilizing a framework such as caliburn micro there is often some form of IOC container already present.

SomeCompositionView view = new SomeCompositionView();
ISomeCompositionViewModel viewModel = IoC.Get<ISomeCompositionViewModel>();
ViewModelBinder.Bind(viewModel, view, null);

Entity Framework in MVVM WPF – Best Way to Wire Up Database Context

I've looked into this quite a bit and haven't found a "perfect" solution. The repository pattern works wonderfully for MVC applications where the context is short lived because it exists in a short lived controller, but the problem happens when you try to apply that same structure to a wpf app where the VM can persist for long periods of time.

I have used this solution in the past which is much more simple than many of the repo patterns I have seen that attempt to abstract things out to an extreme amount, resulting in near unreadable amounts of code that are difficult to debug. Here are the steps...

Create a separate project for the EDMX to act as your Data access layer
Create a "Repositories" folder under the same project
Create a base class "BaseRepository" to act as the "Unit of Work". IDisposable will allow you to use this in a using(){} and the partial will allow you do implement other repositories
```
public partial class MyEntityRepository : IDisposable
{
    MyEntities context = new MyEntities();

    public void Dispose()
    {
        context.Dispose();
    }
}
```

Create another file called "MyOtherRepository". create the same partial class but implement methods based on what you want that file to contain

public partial class MyEntityRepository
{
    public void MyOtherMethodSave(EntityObject obj)
    {
        //work with context
        ...

        context.SaveChanges();
    }
}

Now in your VM you can do this...

using(MyEntityRepository repo = new MyEntityRepository())
{
     repo.MyOtherMethodSave(objectToSave);
}

This groups all your repositories under one class so you don't have to deal with separate context. It allows you better manage different repos by grouping the methods into different files and helps prevent code duplication. On top of that, your contexts are as short lived as they were without using this pattern.

The disadvantage is that with larger systems, you may have a lot of methods that get bundled under your repo. One solution in that case would be to implement some basic common commands like "Find" or "Add", and implement specialized ones in their respective repository.

Best Answer

Related Solutions

C# – How to make creating viewmodels at runtime less painful

Entity Framework in MVVM WPF – Best Way to Wire Up Database Context

Related Topic