What is the real concept and usefulness of POCO classes?

Asked

Viewed 1,623 times

10

I am studying and developing a new project and the little studying on Windows Phone 7.1, I saw that they suggest/ indicate the use of classes POCO, for database mapping (It seems to me that Windows Phone 7.1 uses some version of the EF (Entity Framework) Compact), I did not get to study the case of Windows Phone very thoroughly, because this is not yet the time to study it in depth, I only studied the basics to understand your concepts.

But what I’d like to understand better is:

  1. Why the use of POCO classes?
  2. What advantage this can bring?
  3. Why it is employed in a Project?
  4. And what is actually POCO classes? (Conceptually speaking)
  • 5

    If @brasofilo were reading this I would tell him that I didn’t answer because I understand poco of the subject.

2 answers

10


  1. Why the use of POCO classes?

A POCO object has no dependency on a framework external.

Exemplo: In my business layer, I create POCO objects so that this layer doesn’t have technology dependency and frameworks external. So I can change technologies and/or frameworks without touching my business layer (which is the "heart" of the software).

  1. What advantage this can bring?
  • Minimizes dependency between layers.
  • Minimises maintenance if I change technologies and/or frameworks only infrastructure layers are affected.
  • Increases your testing capacity.
  1. Why it is employed in a Project?

I believe that given the benefits cited in the other answers it is interesting to use.

  1. And what is actually POCO classes? (Conceptually speaking)

"Plain Old CLR Object"

A class without attributes describing infrastructure concerns, frameworks external or other responsibilities that your domain objects should not have.

Examples:

  1. We’re tied to the Entity Framework if we let him create our classes of entities like this:
[EdmEntityTypeAttribute(NamespaceName="SistemaOS.Model", Name="Pessoas")]
[Serializable()]
[DataContractAttribute(IsReference=true)]
public partial class Pessoas : EntityObject
{
    [EdmScalarPropertyAttribute(EntityKeyProperty=true, IsNullable=false)]
    [DataMemberAttribute()]
    public global::System.Int32 id_pessoa
    {
        get
        {
            return _id_pessoa;
        }
        set
        {
            if (_id_pessoa != value)
            {
                Onid_pessoaChanging(value);
                ReportPropertyChanging("id_pessoa");
                _id_pessoa = StructuralObject.SetValidValue(value,"id_pessoa");
                ReportPropertyChanged("id_pessoa");
                Onid_pessoaChanged();
            }
        }
    }
}
  1. A simple example of class POCO:
//Ao trocar meu framework de persistência eu não precisarei mexer nessa classe de negócio
public class Pessoa
{
    public string Nome { get; set; }
    public string Sobrenome { get; set; }
    public int Cpf { get; set; }

    public string NomeCompleto()
    {
        return Nome + " " + Sobrenome;
    }
}
  • So POCO classes are dependency-free classes. Right? They’re similar to DTO So? What’s the difference? (Maybe this is another question?)

  • 3

    @Fernando A POCO class is its domain class and a DTO is the object for transiting data (may have data from more than one entity), so it is not POCO.

  • Renan, but then if I go in the POCO class and put a Dataannotation either validation or ORM mapping, has the original concept of POCO ever fallen? It’s not just a question of referencing data types. I don’t know if I’m clear?

  • 2

    @Fernando Building a POCO class is writing a class that does not depend on anything more than . Net Framework provides. If you use specific Dataannotation for technologies like NH Mapping, Entity Framework, WCF, etc. you are not using POCO.

4

What is POCO?

POCO (Plain Old CLR Object) as well as POJO (Plain Old Java Object) simply means an object that has no internal or external dependency.

The term is used to identify an object as a simple object, rather than the complex and specialized objects that framework such as Orms generally use.

Why use POCO? What advantage can it bring?

  • Allows a simple data storage engine, and simplifies the serializing/moving data between layers.

  • Helps a lot with Dependency Injection and design standard Repository

  • Decreases Complexity and dependency between other layers (The layers that use POCO and POCO references nothing) which helps to reduce the coupling

  • Improves "testability" by simplifying

Reference: Wikipedia

  • 1

    I used its definition of [tag:POCO], to specify in the tag I created for questions related to this concept.

  • @Fernando. Vlw... glad I could help

Browser other questions tagged

You are not signed in. Login or sign up in order to post.