域对象、 POCO 和实体之间的区别是什么?

我的印象是它们基本上都是一样的。模型对象也是一样的吗?

现在,在我的建筑中,我有:

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
}


}

那么以上哪些类是 POCODomain ObjectModel objectentity

70303 次浏览

It's more of a connotation of function; a domain object is something that is specific to your logic implementation and might be more complex than a simple POCO; an entity has a connotation to represent something (usually in reference to a persistence medium), and a POCO is just a quick identifier for a class. A model is just a term used to represent an object (usually containing state and usually dealing with the UI or DB).

It's not that there is any functional difference, they're just different terms to more closely describe something. Like the difference between race car, truck, and family sedan. All are automobiles, but each term is more descriptive.

A domain object is an entity in the domain layer of your application, eg. an Address class. "Model" means the same thing - an entity in the "Domain Model".

A POCO (plain old CLR object) is an object that has no behaviour (methods) defined, and only contains data (properties). POCO's are generally used as DTOs (data transport objects) to carry data between layers, and the data is then commonly used to populate a domain object/entity.

My (non-standard) Layman definitions

  • POCO - Plain Old %Insert_Your_Language% Object. A type with no logic in it. It just stores data in memory. You'd usually see just auto properties in it, sometimes fields and constructors.
  • Domain object an instance of a class that is related to your domain. I would probably exclude any satellite or utility objects from domain object, e.g. in most cases, domain objects do not include things like logging, formatting, serialisation, encryption etc - unless you are specifically building a product to log, serialise, format or encrypt respectively.
  • Model object I think is the same as Domain object. Folks tend to use this interchangeably (I can be wrong)
  • Entity a class that has id
  • Repository a class that speaks to a data storage from one side (e.g. a database, a data service or ORM) and to the service, UI, business layer or any other requesting body. It usually hides away all the data-related stuff (like replication, connection pooling, key constraints, transactions etc) and makes it simple to just work with data
  • Service software that provides some functionality usually via public API. Depending on the layer, it can be for example a RESTful self-contained container, or class that allows you to find a particular instance of needed type.

Original answer

These are terms that are largely used in (Distributed) Domain Driven Design. They are not the same. The term model Object can be used as a synonym to the domain object.

Domain Objects. Objects from the business specific area that represent something meaningful to the domain expert. Domain objects are mostly represented by entities and value objects. Generaly speaking, most objects that live in domain layer contribute to the model and are domain objects.

Entity. An object fundamentally defined not by its attributes, but by a thread of continuity and identity. (Meaning it must have Id)

POCO. A simple object without complicated logic, usually it has just a few properties and is used with ORM or as a Data Transfer Object

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

basically it comes down to internal logic

  1. Domain objects have internal domain logic for things like validation, etc.
  2. Model is basically a light Domain object, they know about the data they hold but nothing really about how it's going to be used
  3. Entities hold data and have some internal knowledge of where it came from, and where it's going to be saved, updated, etc
  4. POCO holds data and may have some internal knowledge about it's self, things like what is the total value of all the items in a property collection
  5. DTO is the simplest item of all, it just holds data and has no logic

They are all basically used for the same thing, it's just how smart you want them to be

according to your code sample The Person class would be a domain object or a model, the other 2 are a service and a repository. Domain objects, Pocos, models, dtos, etc. are used like messages, passed from one layer to the next, a service class like PersonService is a layer in the application and the same with the Repository class like PersonRepository. for a good over view take look at http://bob-the-janitor.blogspot.com/2009/07/n-tier-design-revisit-part-1-over-view.html in this case it's talking about using a data entity which is basically a dto

There are already good explainations of Domain and Model in the answers above.

In a Database-Context Entity means Item in a Entity Relationship Model ERD. (i.e. a Row in a Table)

In the Microsoft-Dotnet-EntityFramework-World Entity means an Object that can be loaded from and saved to a database using a Data(Base)Context. Usually an Entity cannot exist without its Data(Base)Context. (Unit-) Testing the business functionality of these classes is difficuilt.

Pocos (Plain Old CommonRuntime Objects) can exist without the PersistenceFramework (EntityFramework or NHibernate) thus they are much easier to test.

The word poco is the adaptaion of pojo (plain old java object) that were created in the java world for the same reason.