What is the difference between domain objects, POCOs and entities?

I got the impression that they are all basically the same. Are model objects the same?

Now, in my architecture, I:

class Person { public string PersonId; public string Name; public string Email; public static bool IsValidName() { /* logic here */ } public static bool IsValidEmail() { /* logic here */ } } class PersonService { private PersonRepository pRepository; PersonService() { pRepository = new PersonRepository(); } public bool IsExistingEmail(string email) { //calls repo method to see if email is in db } public Person GetPerson(email) { return pRepository.Get(email); } public void SavePerson(Person p) { if (Person.IsValidEmail(p.Email) && !IsExistingEmail(p.Email) { pRepository.Save(p); } } } class PersonRepository { public void Save(Person p) { //save to db } public Person Get(string email) { //get from db } public bool IsExistingEmail(string email) { //see if email in db } } 

So, which of the following classes is POCO , Domain Object , Model object , entity ?

+53
c # architecture domain-driven-design
May 27 '11 at 15:20
source share
6 answers

My (non-standard) Layman definitions

  • POCO - Plain Old% Insert_Your_Language% Object. A type in which there is no logic. It just stores data in memory. Usually you see only auto properties in it, sometimes fields and constructors.
  • Domain object instance of the class associated with your domain. I would probably exclude any satellite or service objects from the domain object, for example. in most cases, domain objects do not include such things as logging, formatting, serialization, encryption, etc. - unless you specifically create a product for registration, serialization, formatting or encryption, respectively.
  • Model object I think this is the same as a Domain object . People tend to use this interchangeably (I may be wrong)
  • Entity class that has id
  • Repository class that speaks to the data store on the one hand (for example, a database, data service or ORM) and with a service, user interface, business layer, or any other requesting authority. It usually hides all data-related data (e.g., replication, pooling, key restrictions, transactions, etc.) and simplifies working with data
  • Service software that provides some functionality, usually through an open API. Depending on the level, it can be, for example, a standalone RESTful container or a class that allows you to find a specific instance of the required type.

Original answer

These are terms that are mostly used in a (distributed) Driven Driven Design project. They are not the same. The term model Object can be used as a synonym for a domain object.

Domain Objects Objects from the field of business that represent something meaningful to a domain expert. Domain objects are mainly represented by value objects and objects. Speaking of a common language, most of the objects that live in the domain layer contribute to the model and are domain objects.

Entity An object fundamentally determined not by its attributes, but by a stream of continuity and identity. (The value must have Id )

POCO. A simple object without complex logic that does not require identification, usually it has only a few properties and is used with ORM or as a data transfer object

class Person - Entity and POCO, an instance of this class - Object Object
class PersonService - Service
class PersonRepository - Repository

+55
May 27 '11 at 15:42
source share

It is rather a connotation of function; a domain object is something specific to your logical implementation and may be more complex than a simple POCO; an entity has a connotation to represent something (usually in relation to a persistence bearer), and POCO is just a quick identifier for a class. A model is simply a term used to represent an object (usually containing state and usually dealing with a user interface or database).

This is not that there is any functional difference, they are just different terms to more accurately describe something. Like the difference between a race car, a truck and a family sedan. All cars, but each term is more descriptive.

+17
May 27 '11 at 15:24
source share

basically it comes down to internal logic

  • Domain objects have internal logical domain things, such as validation, etc.
  • A model is basically a lightweight Domain object, they know about the data that they store, but they don’t know anything about how it will be used
  • Objects store data and have some internal knowledge about where they came from and where they are going to save, update, etc.
  • POCO stores data and may have some internal knowledge about it, such things as what is the total value of all elements in a collection of properties.
  • DTO is the easiest element for everyone, it just stores data and has no logic

All of them are mainly used for the same thing, it's just how smart you are to be

according to your sample code, the Person class will be a domain object or model, the other 2 will be a service and a repository. Domain objects, Pocos, models, dtos, etc. Used as messages sent from one level to another, a service class such as PersonService is a layer in the application and the same with a repository class like PersonRepository. for a good look take a look at http://bob-the-janitor.blogspot.com/2009/07/n-tier-design-revisit-part-1-over-view.html , in which case it talks about using a data object which is basically dto

+12
May 27 '11 at 16:03
source share

The answers above already have good explanations for the Domain and Model.

In the "Database Context" object, it means "Element" in the "ERD Entity Relationship Model" . (i.e. row in the table)

In Microsoft-Dotnet-EntityFramework-World Entity means an object that can be loaded from a database and stored in a database using a Data (Base) context. Typically, an Entity cannot exist without a Data Context (Database). (Unit-) Testing the business functionality of these classes is difficult.

Pocos (Plain old CommonRuntime objects) can exist without PersistenceFramework (EntityFramework or NHibernate), so they are much easier to check.

The word poco is an adaptation of pojo (a plain old Java object) that was created in the Java world for the same reason.

+7
May 31 '11 at 9:10 a.m.
source share

Just a design hint.

Instead of using:

 class PersonService { private PersonRepository pRepository; PersonService() { pRepository = new PersonRepository(); } } 

Using:

 class PersonService { private PersonRepository pRepository; PersonService(PersonRepository pRepository) { this.pRepository = pRepository; } } 

To provide dependency injection in PersonService.

+4
Jan 30 '15 at 15:27
source share

A domain object is an object at the domain level of your application, for example. class of address. “Model” means the same thing - an object in “Domain Model”.

POCO (plain old CLR object) is an object that does not have a specific behavior (methods) and contains only data (properties). POCOs are usually used as DTOs (data transfer objects) to transfer data between layers, and then data is usually used to populate a domain object / object.

+2
May 27 '11 at 15:30
source share



All Articles