32

I'm wondering if anyone can give a solid explanation (with example) of POCO (Plain Old CLR Object). I found a brief explanation on Wikipedia but it really doesn't give a solid explanation.

Chase Florell
  • 46,378
  • 57
  • 186
  • 376

3 Answers3

61

Instead of calling them POCOs, I prefer to call them persistence ignorant objects.

Because their job is simple, they don't need to care about what they are being used for or how they are being used.

Personally I think POCOs are just another buzzword (like Web 2.0 - don't get me started on that) for a public class with simple properties.

I've always been using these type of objects to hold onto business state.

The main benefits of POCOs are really seen when you start to use things like the repository pattern, ORMs and dependency injection.

In other words - you could create an ORM (let's say EF) which pulls back data from somewhere (db, web service, etc), then project this data into objects (POCOs).

These objects can be passed further down the app stack to the service layer, then onto the web tier.

Then if one day you decide to switch over to nHibernate, you should not have to touch your POCOs at all, the only thing that should need to be changed is the ORM.

Hence the term 'persistence ignorant' - they don't care what they're being used for or how they are being used.

So to sum up, the pros:

  • Allows a simple storage mechanism for data, simplifies serialization/passing around through layers
  • Goes hand in hand with depedency injection, repository pattern and ORMs. Flexibility.
  • Minimized complexity and dependencies on other layers. (higher layers only care about the POCOs, POCOs don't care about anything). Loose coupling
  • Simple testability (no stubbing required for domain testing).

Hope that helps.

David Klempfner
  • 8,700
  • 20
  • 73
  • 153
RPM1984
  • 72,246
  • 58
  • 225
  • 350
  • 2
    This makes perfect sense. I like your use of the phrase "buzz word". It appears as though I'm already using this in my project. The use that I'm doing is to pull "some" `User` data using L2S (basically 4 of the 10 fields in the database) and storing them in a very basic "POCO" object. I then serialize that object and store it as the `UserData` object in the ASP.NET Auth Cookie. So that I can retrieve it later without hitting the database again. – Chase Florell Aug 02 '10 at 23:53
  • 1
    @rockinthesixstring - exactly my point. we've been using POCO's for years, its just another way to label something. Personally, i like the combination of repository pattern/dependency injection and ORM's - in this scenario you would be crazy not to use POCO's. It's all about the loose coupling. Of course i have no idea what technology you are using (i'm drawing from my .NET experience) – RPM1984 Aug 02 '10 at 23:56
  • Yeah, as I stated in my comment, I'm using ASP.NET - I'm actually using MVC2. – Chase Florell Aug 02 '10 at 23:57
  • I have a Repository Layer, a Service Layer, and I'm using Linq to SQL as my ORM. I've used the "POCO" for object serialization within a cookie. – Chase Florell Aug 02 '10 at 23:58
  • @rockinthesixstring - nice. MVC rocks! (i also use this). – RPM1984 Aug 02 '10 at 23:58
  • So, then what's the difference between POCO and DTO(Data Transfer Objects) – Vijay Vj Jul 25 '19 at 06:44
3

You need to give more details, such as the context in which you are planning to use POCO. But the basic idea is that you will create simple objects containing only the data/code that is necessary. These objects would not contain any "baggage" such as annotations, extra methods, base classes, etc that might otherwise be required by (for example) a framework.

Justin Ethier
  • 131,333
  • 52
  • 229
  • 284
-3

Example of a POCO:

class Person {

    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string EmailAddress { get; set; }

}
Jordan S. Jones
  • 13,703
  • 5
  • 44
  • 49