Lógica de dominio vs validación de datos

Question

Estoy ocupado leyendo, y disfrutando, Dependency Injection en .Net de Mark Seemann.

Es bastante difícil para mí explicar el contexto exacto, así que no dude en hacer esta pregunta si está familiarizado con el libro.

Mi pregunta tiene que ver con las dos clases de productos en el capítulo 2, página 49. Hay una en la capa de dominio y otra en la capa de acceso a datos. Se explica que la clase de Producto en la capa de acceso a datos fue creada por el asistente Linq to Entity.

Estoy trabajando con Linq en SQL, y podría adornar mi clase de modelo con atributos Ling to SQL, para que no tenga que tener una segunda clase. P.ej.

[Table(Name="Customers")] 
public class Customer 
{ 
    [Column(IsPrimaryKey=true)] 
    public string CustomerID; 
    [Column] 
    public string City; 
} 

Sin embargo, me siento de esta preocupación es la mezcla y, en efecto, fuertemente mi pareja capa de dominio a la LINQ a la capa de acceso de datos SQL. ¿Estás de acuerdo con esto?

Supongamos que creo dos clases de "Cliente" para el dominio y la capa de acceso a datos. Digamos que Ciudad es un campo obligatorio. Al guardar, esta regla debe ser verificada. ¿Debería hacerse esto en la capa de dominio o en la capa de acceso a datos, o en ambas?

Gracias, Daryn

Answer 1

supuesto, que las parejas de su capa de dominio a la DAL. Peor aún, sus entidades de capa de dominio tendrán la misma estructura que las tablas en su base de datos. Si esas tablas son relacionales, entonces esa no será la mejor representación de un modelo de dominio.

Lo que hacemos es dejar que las entidades Linq-to-SQL existan en el DAL, y luego tenemos clases de mapeo en el DAL que convierten las entidades L2S en entidades de dominio, y viceversa. Y eso está bien, porque el DAL es realmente tu ORM, y parte de su trabajo es hacer este mapeo.

Yo diría que si se requiere una ciudad, como una regla de negocios, entonces esa es la lógica de negocios y pertenece como una regla de negocios en la capa de lógica de negocios. Existen paquetes de validación que pueden ayudar con este problema.

Answer 2

Sin embargo, creo que esto está mezclando inquietudes y que en efecto unirá mi capa de dominio a la capa de acceso a datos de Linq a SQL. ¿Estás de acuerdo con esto?

Sí, lo haría. Tanto Entity Framework (primer código) como nhibernate pueden usar clases de mapeo separadas que limpiarían sus modelos sin dependencias con el OR/M.

Una nota al margen: los modelos de dominio no deben tener entidades públicas para las propiedades (en DDD). Ya que mueve efectivamente la lógica del modelo fuera del modelo.

Supongamos que creo dos clases de "Cliente" para el dominio y la capa de acceso a datos. Digamos que Ciudad es un campo obligatorio. Al guardar, esta regla debe ser verificada. ¿Debería hacerse esto en la capa de dominio o en la capa de acceso a datos, o en ambas?

La entidad de base de datos solo debe existir dentro de las clases de repositorio y, por lo tanto, no necesariamente debe validarla. El modelo de dominio que se está guardando ya debería tener el estado correcto.

Ejemplo:

public class ArticleRepository 
{ 
    public void Save(Article article) 
    { 
     // Article is already in a correct state 
     // (thanks to no public setters) 

     var dbEntity = new ArticleEntity(); 
     Mapper.Map(article, dbEntity); 
     _dbContext.Save(dbEntity); 
    } 
}