DataModel vs. DataContract vs. ViewModel

Question

I will have a asp.net MVC that will connect to a WCF webservice. That service defines the database connection.

I noticed I will have 3 different Model/data classes.

First off is the ViewModel guy from MVC. I guess it could be somewhat different from how data is represented in the DB.

Second is the DataModels, poco that define how the objects look in the database.

Then there is the DataContract guy that defines how the objects look that are transferred over the WCF service. Guess it will either be pretty much a representation of a ViewModel or a DataModel.

Is this a overkill or a necessary evil? Should I define the DataContracts as the ViewModel guys perhaps, or even the DataModels.

How would you do it and how would you split it into assemblies?

Answer 1

I would keep them all separate as you mentioned.Tthey each have a different layer to deal (ie belong to) with and should be separate objects to deal with any future changes.

The wcf items will be created by referencing the service so belong in your wcf service. Your data model should be in a model project or a data access project and your ViewModels in your MVC application although you could break then from there if you want but since it's a fairly tight coupling with the MVC app it's debatable.