3

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.

Ivan Bara
  • 565
  • 1
  • 5
  • 7

5 Answers5

6

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.

guillaume31
  • 13,738
  • 1
  • 32
  • 51
  • 1
    good articles. percistance agnostic doesn't have to mean separate DAO's for percistance – Batavia Apr 27 '16 at 15:47
  • Thanks for those articles. I will read them in a minute. You wouldn't call EF model classes DTO's. So, just simple "Person"? – Ivan Bara Apr 28 '16 at 02:27
4

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.

Sampath
  • 63,341
  • 64
  • 307
  • 441
  • Thanks, so did I understand it right? Are you suggesting that I should use my domain model class as an entity for my data layer/entity framework? – Ivan Bara Apr 26 '16 at 03:51
  • Yes,You're right.Go ahead and do that way.Good Luck ! :) – Sampath Apr 26 '16 at 07:33
  • Thanks for this tip, but I don't think it's a good idea. You have to separate concerns, so you can't use domain model as persistence model. Read this http://blog.sapiensworks.com/post/2012/04/07/Just-Stop-It!-The-Domain-Model-Is-Not-The-Persistence-Model.aspx – Ivan Bara Apr 26 '16 at 18:18
  • I'm using ASP.NET ZERO framework for my SPA app. It's having SOLID architecture and Implemented Domain Driven Design and Full multi-tenancy (SaaS) support. On that framework we're using domain models as our entities. You can read it http://aspnetzero.com/ and http://aspnetboilerplate.com/Pages/Documents/Entities – Sampath Apr 26 '16 at 18:47
  • So, why Name in Person is virtual ? – Ivan Bara Apr 26 '16 at 19:32
  • It's for `Lazy loading` – Sampath Apr 26 '16 at 19:33
  • 1
    @IvanBara Regarding the "persistence model", there's actually debate over that. See http://enterprisecraftsmanship.com/2016/04/05/having-the-domain-model-separate-from-the-persistence-model/ – guillaume31 Apr 27 '16 at 09:59
2

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.

Batavia
  • 2,497
  • 14
  • 16
1

Few months back I came across the following article and it does make sense for me while naming classes/entities for my project.

Naming Conventions - XAML made easy

I hople it will help you too

Nouman Bhatti
  • 1,341
  • 6
  • 28
  • 54
0

I also want to adjust DDD principles.

Then the one absolute must is that the names used in the domain model shall match the ubiquitous language of your domain experts.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91