Introduction

POCO stands for Plain Old CLR Object. In .NET, it describes a simple class whose main purpose is to represent data and behavior without being tightly coupled to a framework base class or runtime-specific infrastructure. The term matters because it reflects a design preference for clean domain models that remain easy to test, serialize, and evolve.

What Makes a Class a POCO

A POCO is usually characterized by these traits:

• no required inheritance from framework-specific base types
• no required implementation of infrastructure interfaces just to exist
• simple properties and methods focused on domain meaning
• no hidden runtime magic needed to construct the object

A POCO is not defined by absolute purity. A class can still have validation logic, methods, or even a few attributes and still be considered POCO-style if it remains mostly framework-agnostic.

Simple Example

1public class Customer
2{
3    public int Id { get; set; }
4    public string Name { get; set; } = string.Empty;
5    public string Email { get; set; } = string.Empty;
6
7    public bool HasEmail() => !string.IsNullOrWhiteSpace(Email);
8}

This class is plain, easy to instantiate, and not tied to a persistence or UI framework.

Why POCOs Matter

POCO-style models are useful because they keep business concepts separate from infrastructure concerns. Benefits include:

• simpler unit testing
• easier reuse across layers
• lower coupling to ORM or transport technology
• clearer domain intent

If a framework changes, POCOs are less likely to require wide rewrites than highly framework-dependent models.

POCO and Entity Framework

The term appears frequently in Entity Framework discussions. EF works well with POCO entities because the framework can map simple classes to database tables.

1public class Order
2{
3    public int Id { get; set; }
4    public DateTime CreatedAt { get; set; }
5    public decimal Total { get; set; }
6}

This is preferable to forcing every entity to inherit from a database-specific base class unless your project has a strong reason to do so.

POCO Is Not the Same as Anemic

A common misunderstanding is that a POCO must contain only properties and no behavior. That is not true. A POCO can still hold useful domain logic.

1public class Invoice
2{
3    public decimal Subtotal { get; set; }
4    public decimal TaxRate { get; set; }
5
6    public decimal Total() => Subtotal + (Subtotal * TaxRate);
7}

This is still a POCO-style class. Plain does not mean behaviorless. It means not overly dependent on framework mechanics.

POCO Versus DTO

POCO and DTO are related but not identical ideas.

• POCO describes how plain and framework-independent a CLR object is
• DTO describes a role, usually carrying data between boundaries

A DTO can be a POCO. An entity can also be a POCO. The terms answer different questions.

When a Class Stops Feeling Plain

A class becomes less POCO-like when it is shaped primarily by framework demands, for example:

• mandatory inheritance from infrastructure base type
• lifecycle hooks required by framework internals
• required knowledge of transport or persistence pipeline

That does not automatically make the class wrong. It just means the design is more coupled.

Practical Design Guidance

Use POCO-style classes for:

• domain models
• simple configuration objects
• request and response models
• persistence entities where framework allows plain types

Keep infrastructure concerns in services, repositories, adapters, or mapping layers where possible.

Common Pitfalls

• Assuming a POCO must have no methods at all.
• Confusing POCO with DTO or entity and treating the terms as interchangeable.
• Adding framework dependencies to domain models without clear need.
• Pursuing “pure” POCO design so strictly that useful domain behavior is removed.
• Using the label POCO as a substitute for actual design reasoning.

Summary

• POCO means Plain Old CLR Object in the .NET world.
• It describes classes that stay relatively simple and framework-agnostic.
• POCOs are valuable because they reduce coupling and improve maintainability.
• A POCO can still contain meaningful business behavior.
• Use the term as a design signal, not as a rigid rule divorced from context.