I’m designing a tiered .NET application, and I want to use the Code First approach. I’m new to this, so I’m struggling to envision how it ought to be designed. Would the following be a reasonable approach? What problems or limitations might I run into?
- Write DTO classes for my domain. These will be used for data transfer between the server and client over WCF.
- Write a set of POCO classes that inherits from the DTO classes. Use these to generate the database on the server.
- Write another set of POCO classes that inherits from the DTO classes. Use these to generate an SDF database on the client.
I would do those in a different order-
Firstly, I’d map my business domain, and figure out the best design to solve my business problem. This will give you your domain.
Then, Ideally in a completely different mindset, think about the requirements of your client-side and UI; what data will be displayed, and how? This will give you your DTOs.
Sometimes, the DTOs will resembel your domain classes quite closely. Other times- they will not.
Mapping between them can be made easier with automatic tools such as automapper.
In general, I always advocate to completely separate your domain classes and DTOs.
The gist of it is this- domain classes and DTOs are created to solve different problems. Therefore, they are not related by a ‘is-a’ relationship which is inheritance.
2
I would keep each of these sets of classes separate (the ones for the WFC interaction, the ones for the database, and the ones for the view..the viewmodel). It certainly will seem at first like you’re just duplicating work, which is fine. The benefit is if any of the classes need to be reused somewhere else, then they’re separate and are more portable.
Sometimes you’ll have viewmodels or DTOs where the field names and datatypes match exactly. In this case, use something like Automapper to map from one object to another. This lets you keep things separate while keeping your code clean and making the integration much more painless.