La restricción de longitud de la cadena en las clases de dominio

Question

Tengo un modelo de dominio ignorantes persistencia que utiliza repositorios abstractas de objetos de dominio de carga. La aplicación concreta de mis repositorios (la capa de acceso a datos (DAL)) utiliza marco de la entidad para obtener los datos de una base de datos SQL Server. La base de datos tiene limitaciones de longitud en un lote de sus columnas varchar. Ahora imagina que tengo la siguiente clase de dominio:

public class Case
{
    public Case(int id, string text)
    {
         this.Id = id;
         this.Text = text;
    }

    public int Id { get; private set; }
    public string Text { get; set; }
}

Y un repositorio abstracta definida de la siguiente manera:

public abstract class CaseRepository
{
    public abstract void CreateCase(Case item);
    public abstract Case GetCaseById(int id);
}

La columna [text] de la tabla en sqlserver se define como nvarchar(100)

Ahora sé que he mencionado que mi clase de dominio (Case) fue la persistencia ignorante, sin embargo, siento que es un error que permite para valores del parámetro text que no puede en última instancia ser salvado por mi aplicación concreta repositorio porque el marco de la entidad se producirá una excepción al asignar la propiedad text a la clase generada marco de la entidad cuando es más de 100 caracteres. Así que he decidido que quiero comprobar esta restricción en el modelo de dominio, ya que esto permite que compruebe la validez de datos antes de intentar pasarlo a la DAL, y haciendo así el informe de errores más centrado en el objeto de dominio. Creo que se puede argumentar que solo pude comprobar el constreñimiento en mi constructor y en la incubadora propiedad, pero ya que tengo cientos de clases que todos tienen las mismas limitaciones que quería una de forma más genérica para resolver el problema

Ahora, lo que yo he llegado con una clase llamada ConstrainedString, que se define de la siguiente manera:

public abstract class ConstrainedString
{
    private string textValue;

    public ConstrainedString(uint maxLength, string textValue)
    {
        if (textValue == null) throw new ArgumentNullException("textValue");
        if (textValue.Length > maxLength) 
            throw new ArgumentException("textValue may not be longer than maxLength", "textValue");

        this.textValue = textValue;
        this.MaxLength = maxLength;
    }

    public uint MaxLength { get; private set; }

    public string Value 
    { 
        get 
        {
            return this.textValue;
        } 

        set 
        {
            if (value == null)
                throw new ArgumentNullException("value");
            if (value.Length > this.MaxLength) throw new ArgumentException("value cannot be longer than MaxLength", "value");
            this.textValue = value;
        } 
    }
}

Además tengo una implementación de ConstrainedString llamada String100:

public class String100 : ConstrainedString
{
    public String100(string textValue) : base(100, textValue) { }
}

Lo que conduce a una implementación diferente de Case que se vería así:

public class Case
{
    public Case(int id, String100 text)
    {
         this.Id = id;
         this.Text = text;
    }

    public int Id { get; private set; }
    public String100 Text { get; set; }
}

Ahora, mi pregunta es; Estoy pasando por alto algunas clases incorporadas o algún otro enfoque que podría utilizar en su lugar? O se trata de un enfoque razonable?

Cualquier comentario o sugerencia son bienvenidos.

Gracias de antemano

Answer 1

Creo que su validación debe residir en su modelo de dominio. Las limitaciones en sus campos representan directamente algo de lógica de negocios. En última instancia, usted tiene que validar antes de que persiste de todos modos.

Answer 2

creo que esto depende de muchos factores (así como algunas preferencias personales). A veces, la restricción debe formar parte del objeto de dominio - por ejemplo, con los números de seguridad social, números de pasaporte / ... - estos normalmente tienen una longitud fija y no pueden variar como regla de dominio - no es una regla de persistencia de datos (aunque es posible restringir el PP también).

Algunos prefieren no tener este tipo de cheques en su modelo de dominio y en lugar de tener algo como un atributo de la validación de la propiedad que puede ser inspeccionado y ejecutado externa del objeto de dominio por un validador independiente.

El problema que pueda tener con su método (aunque no es difícil moverse) está recibiendo cualquier ORM / Mapper - si usted está utilizando uno - para saber cómo asignar una cadena a / desde el PP a su ConstrainedString <. / p>

El ConstrainedString no podría obtener en torno al tema del objeto de dominio que tiene información adicional sobre la restricción, ya que puede ser que necesite para construir el ConstrainedString

Answer 3

Si cambia las limitaciones de un caso, tiene sentido que tendría que hacer uno nuevo -. Ha cambiado el contrato, y el código de edad ya no se sabrá si se cumplen los requisitos o no

En lugar de preocuparse por lo que su repositorio o no permitirá, a definir lo que permitirá en su clase, y asegúrese de que usted encuentre una manera de trabajar con cualquier repositorio que cambia en el el futuro. Es dueño de su API - sus dependencias no hacen

.