88

I was under the impression they are all basically the same. Are model objects also the same?

Right now, in my architecture, I have:

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 above classes are POCO, Domain Object, Model object, entity?

Nirav Ranpara
  • 15,268
  • 4
  • 40
  • 57
jpshook
  • 4,516
  • 6
  • 34
  • 44

5 Answers5

119

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

oleksii
  • 33,544
  • 11
  • 83
  • 149
  • 4
    Please see my code sample above and let me know how you would apply the terms. – jpshook May 27 '11 at 20:06
  • Good answer. I was ready to answer this one, but that would be a copy of your answer. I can add that besides Entity and Value objects you also have Domain Events etc. All objects and live in Domain layer and contribute to the model are Domain objects. – Magnus Backeus Jun 01 '11 at 12:40
  • You might want to look at this definition: http://stackoverflow.com/questions/725348/poco-vs-dto/725365#725365 – Vijay Patel Jun 02 '11 at 14:15
  • A service may be placed inside the domain layer, but this is not mandatory. A service usually provides a request-response functionality and (to me) you are free to place it at the layer you deem relevant. If a service provides some functionality from the domain, then you can place it there. But if a service deals with 3-rd party integration, for example, you may leave it outside the domain layer. *Service* is an overly-abused word and can mean so much. – oleksii Mar 20 '13 at 15:30
  • 1
    If a POCO does not need to be identified, how then can it be loaded by an ORM. Thats not logical! – Pascal May 11 '16 at 18:04
  • Doesn't POCO just mean "Plain Old C Object?" (Or CLR as the wikipedia puts it, but that would make it a POCLRO) – Dagrooms Mar 09 '17 at 06:31
  • @Dagrooms it does. You can read abbreviations however you like - it's all non-standard terminology. POCO abbreviation is language dependent (C, C++, C#), I've heard POJO (java or javascript), POPO (python), etc – oleksii Mar 09 '17 at 10:29
  • 2
    Why is this blatantly false information the most upvoted and accepted. POJO is **NOT** a type with no logic in it. In fact, Martin Fowler specifically coined the term POJO to contrast against Entity Beans ("we were pointing out the many benefits of encoding business logic into regular java objects rather than using Entity Beans."). https://www.martinfowler.com/bliki/POJO.html – THIS USER NEEDS HELP Apr 20 '18 at 23:14
  • I am sorry you feel this way @THISUSERNEEDSHELP. I don't agree with your comment and I encorage you to write a beter answer. Many folks may not be familiar with Java Entity Beans and this concept is not widely known in many other languages, such as C#, C and C++. In the codebases that I worked with POxO contained no logic or only some very simple logic. Putting complex logic in POxO makes it a heavy object to modify and reuse in valious situations. – oleksii Apr 23 '18 at 11:34
  • 1
    I am sorry if my comment was strongly worded, but again, your personal experience don't really matter when the *coiner* of the term defined POJO to explicitly contain business logic. In fact, he would classify your practice under anemic domain model (https://martinfowler.com/bliki/AnemicDomainModel.html) which he considers to be an anti-pattern, and he recommends that you use POJO instead. Whether it's an anti-pattern is out of scope of this definition, but one thing is clear: POJO does **not** mean an object without any business logic. – THIS USER NEEDS HELP Apr 23 '18 at 18:21
  • Although, I feel a need to make a distinction. I am not saying POJOs have to be logic-heavy although Fowler strongly recommends so. I am just saying the definition of POJO is not determined by the presence of business logic. It's a term created to contrast again what some thought as unnecessarily complex Entity Bean which had to be serializable. In other words, POJO is simply any plain old Java object in its purest form with no platform attached to it. Now, I understand may be it's different in other languages, but for POJO (which almost all PO*O derive from), it's documented clearly – THIS USER NEEDS HELP Apr 23 '18 at 18:28
  • I felt compelled to reply especially because the question was asked in relation to the domain object, which is heavily tied to DDD, which heavily focuses on having a business logic in the domain objects and keeping the service layer thin. POJO is just one way to implement domain object. Again, I am not saying POJOs *should* be business logic heavy. I am just saying, POJO is *not* defined as *not* having business logic, and I pointed out couple of resources in which the original coiner of the term POJO emphasizes business logic heavy object as an counter argument to your definition. – THIS USER NEEDS HELP Apr 23 '18 at 18:49
  • @THISUSERNEEDSHELP oh, I see. This sounds good. Would you like to reword my answer and change the mistakes? I am happy to accept your explanation and I think compunity will benefit from such correction :) – oleksii Apr 24 '18 at 09:50
  • @THISUSERNEEDSHELP, while you might be right that that was Fowler and that group's original definition, I think the definition has since morphed. At least that's how it seems people are using it. Any use I've seen of POXO in the last few years has implied a plain object with properties and their setters/getters w/ little else, and generally not business logic. If Fowler and that group had to create a name to differentiate something from Entity Beans, or to differentiate them from complex objects tied to outside things, then in retrospect, they should've probably just called them... objects. – John Pancoast Apr 23 '20 at 04:19
  • @JohnPancoast An object with setters/getters and little else is a Data Transfer Object (DTO). Sometimes it's a full blown javabean. POJO/POCO's are a rejection of such frameworky nonsense that tries to convince you that you can't solve problems with normal objects without inheriting their magical powers. When you write a good POJO you can't tell if a framework is even being used. – candied_orange Jan 15 '21 at 07:27
  • @THISUSERNEEDSHELP Yeah I take back what I said. I've just seen it used mistakenly for simple DTO/VO's in some scripting lang circles. I've been into the lower, statically typed langs for awhile but have dodged the original reasoning behind POJOs and apparently held onto some old misconceptions. I still think that "Plain old x object" is kind of a silly name if they're just objects but it seems the original intent was necessary due to Java's history with beans or common use of implementing framework'y interfaces. – John Pancoast Jan 16 '21 at 16:34
  • @THISUSERNEEDSHELP While I did incorrectly hold the name of a POXO as a DTO, to expand on my reasoning about the term itself, I suppose I just see them all as objects. Fowler initially created the term to give objects that aren't using framework'y things a name as a means for developers to use them more. I just see objects as objects that do what they do, and today the term isn't used in the same vain, but I do see some need to still use the term POXO to differentiate an object from an object that's implementing something in a framework or following some framework'y convention, etc, I suppose. – John Pancoast Jan 16 '21 at 17:25
20

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

Bob The Janitor
  • 19,164
  • 9
  • 45
  • 71
18

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.

Tejs
  • 38,896
  • 8
  • 64
  • 81
  • I updated to include a code sample, can you please comment? I just want to make sure when I am asking questions, that I am using the correct terms. – jpshook May 27 '11 at 20:04
12

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.

k3b
  • 13,724
  • 6
  • 47
  • 81
  • whats the reason for downvoting? The question was "What is the difference between domain objects, POCOs and entities?" i explained the difference between Entity and Poco – k3b May 31 '11 at 13:52
  • "There are already good explainations of Domain and Model in the answers above." How could I select a answer that depends on other answers as a valid answer? – jpshook May 31 '11 at 15:04
  • np. In retrospect I should have just commented asking you to provide a complete answer. Will think 2x next time. – jpshook May 31 '11 at 18:05
3

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.

MattDavey
  • 8,395
  • 3
  • 29
  • 54
  • Can't a POCO be a entity? I thought POCOs can have behavior but must be persistence ignorant? – jpshook May 27 '11 at 19:49
  • @Developr Yeah, your domain models/entities could indeed be POCO's - this is what's known as an "anemic" domain model - see http://www.martinfowler.com/bliki/AnemicDomainModel.html – MattDavey May 31 '11 at 07:53
  • How would you consider this anemic? How do you define "rich domain object?" If the domain objects cannot interact directly or indirectly with the database, what kind of rich functionality can they have? – jpshook May 31 '11 at 13:28
  • @Developr I'd consider a domain model composed of POCO objects anemic because traditionally POCO classes don't have any rich functionality, just data. Following the Seperation of Concerns principle (http://en.wikipedia.org/wiki/Separation_of_concerns), an object in the domain model should not be concerned with database access at all (hence the popular term "persistence ignorance"). The kind of functionality an entity in the domain model should have would be business logic - they should capture and encapsulate the logical rules & workflows of the problem/domain they represent. – MattDavey Jun 01 '11 at 08:39