Asignar Atributos de Validación De la Entidad de Dominio a DTO

El propósito de la validación es asegurarse de que los datos que entran en su aplicación cumplan con ciertos criterios, con eso en mente, el único lugar en el que tiene sentido validar restricciones de propiedad, como las que ha identificado aquí, es en el punto en el que acepta datos de una fuente no confiable ( es decir, el usuario ).

Puede usar algo como el "patrón de dinero" para elevar la validación a su sistema de tipos de dominio y usar estos tipos de dominio en el modelo de vista donde tenga sentido. Si tener una validación más compleja (es decir, expresar reglas de negocio que requieren un mayor conocimiento que el expresado en una sola propiedad), estas pertenecen a métodos en el modelo de dominio que aplican los cambios.

En resumen, coloque los atributos de validación de datos en sus modelos de vista y déjelos fuera de sus modelos de dominio.

Resulta que AutoMapper puede ser capaz de hacer esto para nosotros automáticamente, que es el mejor escenario.

AutoMapper-users: Transferir atributos de validación al viewmodel?
http://groups.google.com/group/automapper-users/browse_thread/thread/efa1d551e498311c/db4e7f6c93a77302?lnk=gst&q=validation#db4e7f6c93a77302

No he podido probar las soluciones propuestas allí, pero tengo la intención de hacerlo en breve.

¿Por qué no utilizar una interfaz para expresar su intención? Eg:

public interface IProductValidationAttributes {
    [NotEmpty, NotShorterThan10Characters, NotLongerThan100Characters]
    string Name { get; set; }

    [NotLessThan0]
    decimal Price { get; set;}
}

Si utiliza entidades de dominio escritas a mano, ¿por qué no poner sus entidades de dominio en su propio ensamblado y usar ese mismo ensamblado tanto en el cliente como en el servidor? Puede reutilizar las mismas validaciones.

He estado considerando esto también por un tiempo. Entiendo totalmente la respuesta de Brad. Sin embargo, supongamos que quiero usar otro marco de validación que sea adecuado para anotar tanto entidades de dominio como modelos de vista.

La única solución que se me ocurre en papel que aún funciona con atributos sería crear otro atributo que "apunte" a la propiedad de una entidad de dominio que está reflejando en su modelo de vista. He aquí un ejemplo:

// In UI as a view model.
public class UserRegistration {
  [ValidationDependency<Person>(x => x.FirstName)]
  public string FirstName { get; set; }

  [ValidationDependency<Person>(x => x.LastName)]
  public string LastName { get; set; }

  [ValidationDependency<Membership>(x => x.Username)]
  public string Username { get; set; }

  [ValidationDependency<Membership>(x => x.Password)]
  public string Password { get; set; }
}

Un framework como xVal podría ampliarse para manejar este nuevo atributo y ejecutar los atributos de validación en la propiedad de la clase de dependencia, pero con el valor de propiedad de su modelo de vista. No he tenido tiempo de darle más detalles.

¿Algún pensamiento?

En primer lugar, no hay noción de entidad de dominio "estándar". Para mí, la entidad de dominio estándar no tiene ningún configurador para empezar. Si tomas ese enfoque, puedes tener una api más significativa, que en realidad transmite algo sobre tu dominio. Por lo tanto, puede tener un servicio de aplicación que procesa su DTO, crea comandos que puede ejecutar directamente contra sus objetos de dominio, como SetContactInfo, ChangePrice, etc. Cada uno de estos puede elevar ValidationException, que a su vez puede recoger en su servicio y presentar al usuario. Aún puede dejar sus atributos en las propiedades de dto para una validación simple a nivel de atributo/propiedad. Para cualquier otra cosa, consulta tu dominio. E incluso si esta es la aplicación CRUD, evitaría exponer mis entidades de dominio a la capa de presentación.