POCO = Plain Old Class Object

POCO is derived from POJO . The term was invented by Martin Fowler . The POCO (usually) follows the classical precepts of object-oriented programming, such as state and behavior. For example:

classe Porta 
{
    // Estado
    booleano Aberta;

    // Comportamentos
    metodo Fechar() 
    {
        Aberta = falso;
    }

    metodo Abrir() 
    {
        Aberta = verdadeiro;
    }
}

DTO = Data Transfer Object

DTO would be an data transfer object , in Portuguese. It would be more the representation of a data model, therefore, containing only "states" without behaviors.

classe Porta 
{
    // Estado
    booleano Aberta;
}

// Não existe aqui "Abrir" ou "Fechar": aqui se manipula diretamente os valores.
minhaPorta = nova Porta();
minhaPorta.Aberta = falso;
minhaPorta.Aberta = verdadeiro;

Model

A Model , or template , is already somewhat self-explanatory: it represents a data model of some entity about which you want to describe, but not just It also describes relationships between other entities. The more the Model is incremented in the matter of its technological description, the more it approaches a DTO than a POCO .

Framework frameworks often differ on what a Model is approaching. In some cases, such as Django and Ruby on Rails, the Model approaches a POCO . In others, such as ASP.NET MVC and Hibernate, it approaches a DTO .

In any case, the Model is the least useful for a three-tier architecture (as proposed in the question) precisely because it is a design pattern aimed at the operation of a framework MVC, where the objects and relationships between them have a much more technological footprint than in a purely object-oriented architecture. Interestingly, the 3-tier architecture is closer to the purely object-oriented approach than MVC.