Common models for WPF and ASP.NET MVC

Question

I am going to build two applications. One of them in WPF and second one in ASP.MVC. I decided to create a webservice which will be a layer between database and my applications. I don't want to use entity models in my apps. I want to create lightweight models, send them to webservice and then translate them to the entity models. My question is how to create a common models for WPF and MVC? I don't know how to do that because I want to use data annotation attributes for MVC and also implement INotifyPropertyChanged interface for WPF. There were will be also others things I think. Is there some good approach for doing it? Or it is impossible?

Answer 1

Well, first and foremost, there's nothing wrong with exposing entity classes outside of the DAL. They're just classes. There's nothing special about them. What makes them do database stuff is their inclusion in a DbContext class, and you could actually move all the annotations and other config into the context using fluent config and have pristine classes without any sort of outside influence in them.

Also, there's a tendency to add too much config to entity classes anyways. They should only have things that are important at a database level . Things like [EmailAddress] which instruct how a property should be validated on post are inappropriate on an entity class.

That said, the place to put things like [EmailAddress] and other view-specific things is on view models. Which should pretty much clear up the rest of your confusion. Need to implement INotifyPropertyChanged ? Do so with a view model. and map your entity data to/from it.

Just don't do like I've seen some people do and create a DTO class that's basically an exact copy of your entity class solely to transfer the data from one place to another in your app. That's useless and only adds additional things to maintain and additional work your app needs to perform with no benefit. The entity class is a DTO. Return it from your service and then map to your view model. Done.

Just to clarify the last bit, the classes that matter to your WPF/MVC apps should be their view models, and those will be unique to the app. The logic for what is needed in WPF and how to map entity data to/from that belongs to the WPF app. It would be 100% inappropriate to have code creating class instances to be used directy in a WPF app to be created by some service that's supposed to be concerned with getting the data in the first place. This would be a violation of the single-responsibility principle. Let each thing do what it's designed to do. Keep WPF code with WPF code, in other words. You could still have some library that handles mapping between the data layer and your WPF view models, but that should be a separate thing which would only be a dependency in your WPF app.