Why using POCO classes?
A POCO object has no dependency on an external framework .
Exemplo:
In my business layer, I create POCO objects so that this layer does not have
dependence on technologies and external frameworks. Thus, I can change technologies and / or
frameworks without messing with my business layer (which is the "heart" of the software).
What is the advantage that this can bring?
- Minimizes dependency between layers.
- Minimize maintenance, if I switch technologies and / or frameworks only the infrastructure layers are affected.
- Increases your ability to test.
Why is it used in a Project?
I believe that given the benefits mentioned in the other answers, it is interesting to use them.
And what is actually POCO classes? (Conceptually speaking)
"Plain Old CLR Object"
A class with no attributes that describe the infrastructure concerns, external frameworks, or other responsibilities that your domain objects should not have.
Examples:
We are tied to the Entity Framework if we let it create
our entity classes 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();
}
}
}
}
A simple class example 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;
}
}