'POCO' definition

Question

Can someone define what exactly 'POCO' means? I am encountering the term more and more often, and I'm wondering if it is only about plain classes or it means something more?

Solution 1

"Plain Old C# Object"

Just a normal class, no attributes describing infrastructure concerns or other responsibilities that your domain objects shouldn't have.

EDIT - as other answers have stated, it is technically "Plain Old CLR Object" but I, like David Arno comments, prefer "Plain Old Class Object" to avoid ties to specific languages or technologies.

TO CLARIFY: In other words, they don’t derive from some special base class, nor do they return any special types for their properties.

See below for an example of each.

Example of a POCO:

public class Person
{
    public string Name { get; set; }

    public int Age { get; set; }
}

Example of something that isn’t a POCO:

public class PersonComponent : System.ComponentModel.Component
{
    [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
    public string Name { get; set; }

    public int Age { get; set; }
}

The example above both inherits from a special class to give it additional behavior as well as uses a custom attribute to change behavior… the same properties exist on both classes, but one is not just a plain old object anymore.

Solution 2

Most people have said it - Plain Old CLR Object (as opposed to the earlier POJO - Plain Old Java Object)

The POJO one came out of EJB, which required you to inherit from a specific parent class for things like value objects (what you get back from a query in an ORM or similar), so if you ever wanted to move from EJB (eg to Spring), you were stuffed.

POJO's are just classes which dont force inheritance or any attribute markup to make them "work" in whatever framework you are using.

POCO's are the same, except in .NET.

Generally it'll be used around ORM's - older (and some current ones) require you to inherit from a specific base class, which ties you to that product. Newer ones dont (nhibernate being the variant I know) - you just make a class, register it with the ORM, and you are off. Much easier.

Solution 3

I may be wrong about this.. but anyways, I think POCO is Plain Old Class CLR Object and it comes from POJO plain old Java Object. A POCO is a class that holds data and has no behaviours.

Here is an example written in C#:

class Fruit 
{
    public Fruit() { }

    public Fruit(string name, double weight, int quantity) 
    {
        Name = name;
        Weight = weight;
        Quantity = quantity;
    }

    public string Name { get; set; }
    public double Weight { get; set; }
    public int Quantity { get; set; }

    public override string ToString() 
    {
        return $"{Name.ToUpper()} ({Weight}oz): {Quantity}";
    }
}

Solution 4

POCO stands for "Plain Old CLR Object".

Solution 5

In .NET a POCO is a 'Plain old CLR Object'. It is not a 'Plain old C# object'...

View more solutions

Comments

[EnocNRoll - AnandaGopal Pardue]

It's also funny that "poco" is a Spanish word meaning "little, not much". So, it fits this context nicely! en.wiktionary.org/wiki/poco

[BlackBear]

It means the exact same thing in italian too :)

[Ismael]

And in Portuguese means a error because it is spelled: "pouco".

[usefulBee]

Sounds like PocoHaram to me :)

[titol]

In Polish "POCO" is question "Why use it"

[David Arno]

I would view a POCO as a plain old class that doesn't try to be part of the trendy pattern set. However I like your answer too.

[David Mohundro]

Agreed - not a fan of the C# name, but that was what I first heard when I was wondering about the question :) Class then fits POJO, POVBO POC#O, POC++O, PORO, etc.

[philant]

just for the sake of completeness, CLR stabds for Common Language Runtime - the .net virtual machine.

[Lucas]

.Net 3.5 sp1 ORM example: the Entity framework requires that classes inherit from a certain framework class. LINQ to SQL does not have this requirement. Therefore LINQ to SQL works with POCOs and the Entity framework does not.

[PositiveGuy]

This doesn't really give a good answer in my personal opinion as someone also curious. Ok, so no attributes describing infrastructure (what do you mean by attributes and infrastructure...a DB connection for example? what? example please). What responsibilities should your domain objects not have? So POCO is a domain object (BL object) basically? So really POCO is just another acronym for a Business Layer Object / Domain Object which all mean the same damn thing. POCO / Business Layer Object / Domain Object == same damn thing, just 3 different acronyms for the same concept right?

[PositiveGuy]

ooooook? so what does that mean in context or the real world?

[PositiveGuy]

What really is needed here are references to some examples...some real world classes that are considered POCO.

[PositiveGuy]

this reply tells me absolutely nothing about what it is in the real world...just a definition that anyone can look up on Wikipedia. How's about some example POCO classes?? and why they are POCO in context.

[PositiveGuy]

"Just a normal class, no attributes describing infrastructure concerns or other responsibilities that your domain objects shouldn't have." Define "normal class" and "no attributes describing infrastructure or other responsibilities". I have no idea what this means in specific context.

[mistertodd]

And as my high school electricity teacher would say, "...and oranges taste orangey"

[mistertodd]

So is it safe to say: It's a class you created to do something. You didn't descend from something to inherit special functionality, and nobody's ever going to descend from it. It's just a plain old class that you wrote to do something. (?)

[David Mohundro]

@Ian Boyd, yes, I think that's a fair assessment.

[anar khalilov]

Right, but this post looks like more a comment, rather than an answer since it does not completely answer the question.

[rory.ap]

I have to agree with @CoffeeAddict; I came here not having heard this term before, and after reading this answer, I still don't know what it means. "no attributes describing infrastructure concerns or other responsibilities that your domain objects shouldn't have." -- what types of infrastructure concerns/responsibilities? Can you provide examples?

[rory.ap]

"they don’t derive from some special base class, nor do they return any special types for their properties." -- what constitutes a "special" base class? How would I know when I see one so that I can avoid deriving from it? Same with "special types".

[David Mohundro]

As an example, a class you wrote that only inherits from System.Object is a POCO. If it inherits from ExternalFramework.OrmMapperBase or something like that, it isn't a POCO anymore.

[RBT]

AFAIK POCO objects have only member variables, manual and auto-implemented properties. They are mostly used for data transfer across layers like for data coming from Model towards application layer. Does an object qualify to be a POCO if I define additional methods in it as well? e.g. an Employee class has two properties named FirstName and LastName and I've defined a method as well in the class as GetFullName.

[David Mohundro]

@RBT I'd personally say that yes, it still qualifies POCO, particularly if the methods don't modify any state.

[Héctor Álvarez]

This should be the accepted answer. It provides the actual explanation (It has no behaviors) and also has an example for better understanding what a POCO looks like.

[trajekolus]

Isn't the ToString() method in this example a "behaviour"?

[user3285954]

This answer is vague, raises even more questions so shouldn't be accepted or upviotd.

[user3285954]

I would argue about a POCO not having behaviour. It is simply a class what doesn't depend on other framework/library than .Net. I.e. the File class is POCO, but DbContext is not because depends on Entity Framework.

[David Mohundro]

I added an example of both a POCO and something that isn’t a POCO. Because there (arguably) isn’t consensus on if methods make something not a POCO or not, my examples don’t have them. Hopefully the examples are extreme enough to show something that is clearly a POCO and something that isn’t, though.

[Grx70]

@DavidMohundro I think your example is misleading because it lacks an explanation of why it isn't a POCO. We know that a) it derives from Component and b) it has a property decorated with [DesignerSerializationVisibility]. Is it because both a) AND b) are satisfied, or because either is satisfied? And if the latter, where do you draw the line of permitted attribute usage (or "attributes describing infrastructure concerns")? Is [DataMember] a POCO-breaker attribute? Or perhaps a XML specific attribute when you want to serialize it into JSON?

[Jeppe]

Your description sounds more like a Data Transfer Object (DTO). See this comparison of POCO vs DTO.

[tetrahydrocannon]

A POCO class can definitely has behavior (validation, calculation, transformation...) as long as the behavior doesn't depend on anything else than CLR basic types (string, int, bool...) and sibling POCO classes.

[Peter]

its just like, Plain Old Reversible Named Object.