- 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).
- 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.
- Why it is employed in a Project?
I believe that given the benefits cited in the other answers it is interesting to use.
- 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:
- 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();
}
}
}
}
- 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;
}
}
If @brasofilo were reading this I would tell him that I didn’t answer because I understand poco of the subject.
– Bacco