Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.
share|improve this question
add comment

2 Answers

up vote 7 down vote accepted

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.

share|improve this answer
    
Very helpful thanks. One of the reasons that I was thinking using Code First with POCO's would be beneficial, was that I'd get to re-use the POCO classes on both the server and client (just swapping out the dbContext). I guess that's not really the case, huh? –  Eric Jul 19 '12 at 22:18
    
no, since, like i said- they serve different purposes –  sJhonny Jul 20 '12 at 7:54
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.