MVVM Reporting App Approach ? Data Access Layer?

Question

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?

• Alex Hope O'Connor: It seems like quite a logical approach, its good to keep the data access seperate from the view models.
• yannis: @AlexHopeO'Connor If you could expand that in an answer, it may very well be a good answer. But you need to explain why it's a logical approach.

Answer 1

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.

• Dan J: +1 This. Further to the "mysterious black box", we typically abstract our DAL behind an IRepository interface and inject an implementation of the repository into the ViewModels. The Repository might access a database, remote services, or mock data, depending on your configuration; and the ViewModels are none the wiser.
• Rachel: @djacobson I agree, but didn't want to make things too confusing :)
• whytheq: (upped) for answer, particularly "mysterious black box"

Answer 2

From what I have learned with MVVM you should only allow the Model to access the data layer and then the ViewModel can interact with the Model to get the information it needs. the ViewModel can then pass on this information through to the View.

Have you considered using any MVVM frameworks to lighten the load of developing?

If not, may I suggest using Caliburn.Micro with Unity?

These will both help you get started with MVVM and are very useful.

• Rachel: Nooooooo don't do that! Models are dumb objects meant for holding data, they should not perform any kind of Data Access!
• stuartmclark: @Rachel should I have a data access layer then that either the Model/ViewModel interacts with. I can see where you are coming from with the "dumb" comment and it makes sense. I am unsure of who interacts with the Data access layer then?
• Rachel: The ViewModel is usually the one to interact with the DAL. Sometimes the DAL is hidden behind another layer, the Repository layer, which is usually the "black box" that does all the data access calls. I've used both methods before (calling the DAL directly from my VM, or working with a Repository object from my VM), and which one I use is usually based on my project's size.
• Matthew Flynn: @Rachel--you really do have this backwards--the Model is NOT "dumb objects"--it is the model of your business domain, which can very well have logic and will probably be persistent in some manner. Now you probably want to segregate the means of persistence using DAOs or something, but that would be underneath the Model. The purpose of the ModelView is simply to map/bind the View (UI) to the model. The ModelView should not even care about persistence.
• whytheq: @MatthewFlynn check out this article msdn.microsoft.com/en-us/magazine/dd419663.aspx the ViewModel talks to the Repository.