I am currently working on an application that has all its entities coming from straight from Linq2SQL. Trying to find a way to keep everything cleanly separated, I added a domain model for the type that came from Linq2SQL and wrapped that with a ViewModel.
This added a little bit of complexity to my code, as I have a service layer and in it when initializing I got the entity from L2S, newed my domain class, and filled it with whatever data was in the entity.
When I wanted to insert the item back into the database in L2S, I ran into a problem which made me do the reverse: fill an entity with the data from the domain class. At this point I started to doubt if I was on the right path, so I started to think about what I have done wrong, or just possibly thought was the right way but ultimately wasn’t.
I ended up thinking that wrapping the entity instead of filling a domain model and wrapping that, was maybe the right way to go in this situation. If I wouldn’t do something like this, I would need to have a using statement in the ViewModel of my View pointing to the DAL. Maybe I’m mistaken, but as far as I read (in books, internet articles), that is not a clean separation of concerns.
So, hence my question:
When there are no domain models, is the ViewModel for the Model used to keep the DAL out of the ViewModel of the View?
Your question is a bit vague. However I see a lot of confusion in the comunity about the MVVM pattern. A lot of people “Wrap” the model in the ViewModel, like what you’re doing, and this is wrong.
The Model is basically your L2S Objects.
The ViewModel, exposes the L2S objects directly, and handles interaction logic, i.e. handle commands, object updates, etc. (doesn’t wrap anything, just as a link to them).
Wraping is wrong, let’s say for example that you want something that is too complex for a converter, yet you need to have it on your Entity (BusinessObject or whatever comes out of L2S – Your ORM framework), you should extend your Entity to support this.
I’ll give you some examples, however these are from a slightly different architecture:
This is a list of Tasks in this application, the final result is a view like project with a gantt chart.
The ViewModel looks like this:
As you can see it has specific converters there, some objects we use to create some extra UX functionality and handles command interaction directly from the View.
The Task (here called Tarefa from portuguese naming) itself is an Entity Framework Self Tracking Entity, and it is extended by adding a second partial class definition. The STE T4 template itself isn’t that much tweaked, most of the customization is done by adding extra partial class definition to objects we want to customize.
As you can see, it’s mostly getters that return stuff that we want to bind to the View directly, that isn’t apart of the Model. This practice makes development very fast, as writing converters can be quite complex for some types of exposures.
This is a lot of code, but hopefully will give you an idea of what to write on the ViewModel and what to write on the Model, how to extend the Model and how you bind stuff around.