Naming conventions for model in multi layer application

问题

I'm a new developer I have never worked in big enterprise company so I have a question about naming conventions in multi-layer application. I have a WPF/MVVM application, with EF data layer. I also want to adjust DDD principles.

So, I three models of the same class I would say. I have "model" in MVVM, I have a entity/dto(I don't know?) in EF, I have domain model/POCO in DDD. I have to create all those 3 classes to separate concerns (maybe I could merge MVVM model with POCO. I mean, POCO is kinda model in MVVM). How should I name them?

Let's say I have Person POCO. Should it be "Person" or "PersonDto" in EF? What's the general convention? I've met both ways w/wo Dto postfix, so I'm confused.

回答1:

I usually suffix the DTOs and ReadModels/ViewModels, but not the domain objects.

There's no hard and fast rule, it's a matter of personal (or team) preference. Some like to let namespaces do the trick instead, but I find it less explicit.

Edit : btw, I'm not a huge fan of having a separate "persistence model" (and I'm not the only one). And in any case, I wouldn't call objects in that layer DTO's.

回答2:

DTO : e.g: PersonDto

A DTO is an object that defines how the data will be sent over the network.

POCO : e.g: Person

The Entity Framework enables you to use custom data classes together with your data model without making any modifications to the data classes themselves. This means that you can use "plain-old" CLR objects (POCO), such as existing domain objects, with your data model. These POCO data classes (also known as persistence-ignorant objects), which are mapped to entities that are defined in a data model, support most of the same query, insert, update, and delete behaviors as entity types that are generated by the Entity Data Model tools.

Hope this helps to you.

回答3:

I think important to remember is that a Person is not a Person. The reason you want to separate them is because they might do very different things.

For example i could have

People database class/object

(a subset of which) which maps to Student Domain objects

and then the frontend send a AddressChange update for the student.

Of course you could also have Person, PersonDTO and PersonDB and even a PersonVM (say you are using javascript types in the frontend). The thing to remember is that is that you separate them because they are "completly different". If you are forcing them to be always exactly the same then there is really no reason to separate them.