3

My question is in regard to the first "M" in MVVM, the model. I see a ton of variations on how to implement the model. Some are just POCO's with no business logic and no persistence logic, and others contain one or both.

Right now, in our application, we have a decent separation between models, views, and view-models. This is our current solution structure (its a WPF prism application):

  • Infrastructure
  • Module A
    • ViewModels
    • Views
  • Module B
    • ViewModels
    • Views
  • Models (shared amongst modules, which is why its in its own class library)
  • Services
  • DataAccess (possibly utilizing dapper-dot-net)
  • Shell (main WPF project)

We now need to figure out how to perform our CRUD against the database and keep our models updated. I like the idea of keeping the models pretty bare-bones and having a "Services" class library that contains our business logic and performs a unit of work pattern against our data access classes. Are there any known issues with keeping the models dumb and ignorant of business logic / data access? Is this pretty uncommon to do in MVVM?

I wonder if I'm limiting myself or making things more complex than they need to be by not placing some logic in the models, for example, loading a model from within its ctor given an argument. As a note, this will be a large application.

Our application will have to persist models to multiple databases. We're using Unity as our dependency injection container for our services. How would you recommend I tell the service which data connection to use? Ctor, per function, etc?

Kinda looking for someone who built a similar structure, and what their experiences were / recommendations are.

Filburt
  • 17,626
  • 12
  • 64
  • 115
Chris Klepeis
  • 9,783
  • 16
  • 83
  • 149

1 Answers1

5

In my view, MVVM models just 'represent' the data and should therefore not have any logic, CRUD or otherwise embedded. You already have the Data Access Layer so it is perfectly normal to write your CRUD code there and to use DI to access this CRUD code from your models.

The "beauty" of MVVM is that it is open to interpretation so I'm sure someone else would argue that model IS the data and it can containt CRUD logic...

I have all my CRUD operations in my DAL and am yet to see the downside of that approach...

Dean Kuga
  • 11,878
  • 8
  • 54
  • 108
  • 1
    In addition, MVVM is not an application architecture pattern, but it is meant to be a pattern to design user interfaces in a more standardized way. So when it comes to data, MVVM is not the means of choice. – PVitt May 31 '12 at 10:06
  • Thanks. I ended up using the Unit of Work pattern with services / repositories on top of all of that to populate and persist my models. – Chris Klepeis Jun 01 '12 at 18:53