MVVM Reporting App – Data Access Layer Approach

clinqmvvmwpf

I'm trying to follow the MVVM pattern in a reporting / statistics application that I'm making in C# / WPF.

I have made many model classes to hold properties as a starting point. Some of these models are made to encapsulate different statistics so that I can present data that can be cross refrenced.

I'm thinking the next step is to create a data access layer with classes and methods to connect to a database and grab the values to populate these models.

I was thinking of creating a connection and query passing class. Then other classes for each specific set of data that I will need for the models. (constructing queries to pass)

From what I understand I will be calling these data access layer methods from the view model to populate instances of my models. Which I will present with the view.

Is my approach in theory the correct standard way to approach this problem? Any suggestions? Or Reference Material?

Best Answer

You're definitely on the right track in making a Data Access Layer, although I would suggest making it more like a mysterious black box whose inner workings are unknown.

What I mean by this is your objects should be able to use the DAL to get/save objects, but they should have no idea how the data is actually obtained.

For example, instead of your ViewModel saying DAL.GetDataSet(someConnection, someQuery), you should call DAL.GetAccounts() which returns a list of AccountModel objects. The ViewModel should not care how or where the data is obtained from, only that it can magically get the objects it needs from the mysterious DAL object.

This keeps your data layer entirely separate, so if you ever need to change it out or adjust the queries, its all in one central location.

As a side note, your ViewModels should be the layer accessing the DAL. Models are simply dumb objects which contain data. They should have no advanced functionality, such as data access.

Related Solutions

MVVM Lists & Collections – Which Approach to Take?

Yes, both ways are valid. There are pros and cons to each approach.

If the Person can be displayed in several different ways depending on the context - whether it's in a ListBox or on a "page" then using your technique with an ItemTemplate to control how it's displayed in the list is probably the better way to go.

I think you need to look at your overall design and see which fits best. Changing the implementation part way through is a bad idea though. Some "pages" will be the old style and others will be the new, leading to inconsistencies in the user experience and potentially increased effort in maintaining and extending the system. If nothing else, you will have to go through the existing code to make it conform to the new format.

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

MVVM Lists & Collections – Which Approach to Take?

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

Related Topic