puede - Los modelos POCO, DTO, DLL y Anemic Domain

el programa no puede iniciarse porque falta tag dll en el equipo

Question

Estaba viendo las diferencias entre POCO y DTO (parece que los POCO son dto con comportamiento (¿métodos?)) Y encontré este artículo de Martin Fowler sobre el modelo de dominio anémico.

Por falta de comprensión, creo que he creado uno de estos modelos de dominio anémicos.

En una de mis aplicaciones, tengo las entidades de mi dominio comercial definidas en un dll ''dto''. Tienen muchas propiedades con getter''s y setter''s y no mucho más. Mi código de lógica de negocios (poblar, calcular) está en otro dll ''bll'', y mi código de acceso a datos está en un dll ''dal''. ''Mejor práctica'', pensé.

Entonces típicamente creo un dto así:

dto.BusinessObject bo = new dto.BusinessObject(...)

y pasarlo a la capa de bll así:

bll.BusinessObject.Populate(bo);

que a su vez, realiza un poco de lógica y la pasa a la capa dal de la siguiente manera:

dal.BusinessObject.Populate(bo);

Desde mi punto de vista, para convertir mi dto en POCO, necesito hacer que la lógica comercial y el comportamiento (métodos) formen parte del objeto. Entonces, en lugar del código anterior, es más como:

poco.BusinessObject bo = new poco.BusinessObject(...)
bo.Populate();

es decir. Estoy llamando al método en el objeto en lugar de pasar el objeto al método.

Mi pregunta es: ¿cómo puedo hacer esto y aún retener las capas de "mejores prácticas" de preocupaciones (dll''s separados, etc.). ¿Llamar al método sobre el objeto significa que el método debe definirse en el objeto?

Por favor, ayuda mi confusión.

Answer 1

Creo que la mejor manera de aclarar esto es por definición:

DTO: Objetos de transferencia de datos:

Solo sirven para el transporte de datos, normalmente entre la capa de presentación y la capa de servicio. Nada menos o más Generalmente se implementa como clase con get y sets.

public class ClientDTO
{
    public long Id {get;set;}
    public string Name {get;set;}
}

BO: Objetos comerciales:

Los objetos comerciales representan los elementos de negocio y, naturalmente, la mejor práctica dice que también deben contener la lógica de negocios. Como dijo Michael Meadows, también es una buena práctica aislar el acceso a los datos de estos objetos.

public class Client
{
    private long _id;
    public long Id 
    { 
        get { return _id; }
        protected set { _id = value; } 
    }
    protected Client() { }
    public Client(string name)
    {
        this.Name = name;    
    }
    private string _name;
    public string Name
    {
        get { return _name; }
        set 
        {   // Notice that there is business logic inside (name existence checking)
            // Persistence is isolated through the IClientDAO interface and a factory
            IClientDAO clientDAO = DAOFactory.Instance.Get<IClientDAO>();
            if (clientDAO.ExistsClientByName(value))
            {
                throw new ApplicationException("Another client with same name exists.");
            }
            _name = value;
        }
    }
    public void CheckIfCanBeRemoved()
    {
        // Check if there are sales associated to client
        if ( DAOFactory.Instance.GetDAO<ISaleDAO>().ExistsSalesFor(this) )
        {
            string msg = "Client can not be removed, there are sales associated to him/her.";
            throw new ApplicationException(msg);
        }
    }
}

Servicio o clase de aplicación Estas clases representan la interacción entre el usuario y el sistema y harán uso tanto de ClientDTO como de Client.

public class ClientRegistration
{
    public void Insert(ClientDTO dto)
    {
        Client client = new Client(dto.Id,dto.Name); /// <-- Business logic inside the constructor
        DAOFactory.Instance.Save(client);        
    }
    public void Modify(ClientDTO dto)
    {
        Client client = DAOFactory.Instance.Get<Client>(dto.Id);
        client.Name = dto.Name;  // <--- Business logic inside the Name property
        DAOFactory.Instance.Save(client);
    }
    public void Remove(ClientDTO dto)
    {
        Client client = DAOFactory.Instance.Get<Client>(dto.Id);
        client.CheckIfCanBeRemoved() // <--- Business logic here
        DAOFactory.Instance.Remove(client);
    }
    public ClientDTO Retrieve(string name)
    {
        Client client = DAOFactory.Instance.Get<IClientDAO>().FindByName(name);
        if (client == null) { throw new ApplicationException("Client not found."); }
        ClientDTO dto = new ClientDTO()
        {
            Id = client.Id,
            Name = client.Name
        }
    }
}

Answer 2

Normalmente, no desea introducir persistencia en los objetos de su dominio, ya que no forma parte de ese modelo comercial (un avión no se construye a sí mismo, sino que vuela pasajeros / carga de un lugar a otro). Debe usar el patrón de repositorio , un marco ORM u otro patrón de acceso a datos para administrar el almacenamiento persistente y la recuperación del estado de un objeto.

Donde entra en juego el modelo de dominio anémico es cuando haces cosas como esta:

IAirplaneService service = ...;
Airplane plane = ...;
service.FlyAirplaneToAirport(plane, "IAD");

En este caso, la administración del estado del avión (ya sea que esté volando, dónde está, cuál es la hora / aeropuerto de salida, cuál es la hora / aeropuerto de llegada, cuál es el plan de vuelo, etc.) se delega a algo externo al avión. .la instancia de AirplaneService.

Una manera POCO de implementar esto sería diseñar su interfaz de esta manera:

Airplane plane = ...;
plane.FlyToAirport("IAD");

Esto es más fácil de descubrir, ya que los desarrolladores saben dónde mirar para hacer volar un avión (simplemente dígale al avión que lo haga). También le permite asegurarse de que el estado solo se administre internamente. A continuación, puede hacer que las cosas como la ubicación actual sean de solo lectura y asegurarse de que solo se modifiquen en un solo lugar. Con un objeto anémico de dominio, dado que el estado se establece externamente, descubrir dónde cambia el estado se vuelve cada vez más difícil a medida que aumenta la escala de su dominio.

Answer 3

Personalmente, no encuentro tan malos modelos de dominio anémico; Me gusta mucho la idea de tener objetos de dominio que representen solo datos, no comportamientos. Creo que el principal inconveniente de este enfoque es la capacidad de descubrimiento del código; necesita saber qué acciones están disponibles para usarlas. Una forma de evitar eso y aún mantener el código de comportamiento desacoplado del modelo es introducir interfaces para el comportamiento:

interface ISomeDomainObjectBehaviour
{
    SomeDomainObject Get(int Id);
    void Save(SomeDomainObject data);
    void Delete(int Id);
}

class SomeDomainObjectSqlBehaviour : ISomeDomainObjectBehaviour
{
    SomeDomainObject ISomeDomainObjectBehaviour.Get(int Id)
    {
        // code to get object from database
    }

    void ISomeDomainObjectBehaviour.Save(SomeDomainObject data)
    {
        // code to store object in database
    }

    void ISomeDomainObjectBehaviour.Delete(int Id)
    {
        // code to remove object from database
    }
}
class SomeDomainObject
{
    private ISomeDomainObjectBehaviour _behaviour = null;
    public SomeDomainObject(ISomeDomainObjectBehaviour behaviour)
    {

    }

    public int Id { get; set; }
    public string Name { get; set; }
    public int Size { get; set; }


    public void Save()
    {
        if (_behaviour != null)
        {
            _behaviour.Save(this);
        }
    }

    // add methods for getting, deleting, ...

}

De esta forma, puede mantener la implementación del comportamiento separada del modelo. El uso de implementaciones de interfaz que se inyectan en el modelo también hace que el código sea más fácil de probar, ya que puede simular fácilmente el comportamiento.