Restringindo o comprimento da string em classes de domínio

Question

Eu tenho um modelo de domínio ignorante de persistência que usa repositórios abstratos para carregar objetos de domínio.A implementação concreta dos meus repositórios (a camada de acesso a dados (DAL)) usa estrutura de entidade para buscar dados de um banco de dados do SQL Server.O banco de dados possui restrições de comprimento em muitas de suas colunas varchar.Agora imagine que eu tenho a seguinte classe de domínio:

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; }
}

E um repositório abstrato definido da seguinte forma:

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

O [text] coluna da tabela no sqlserver é definida como nvarchar(100)

Agora eu sei que mencionei que minha classe de domínio (Case) era persistência ignorante, no entanto, sinto que é errado que isso permita valores do text Parâmetro que não pode ser salvo pela minha implementação de repositório concreto, porque a estrutura da entidade lançará uma exceção ao atribuir o text propriedade para a classe gerada pela estrutura da entidade quando ela tiver mais de 100 caracteres.Por isso, decidi que desejo verificar essa restrição no modelo de domínio, porque isso me permite verificar a validade dos dados antes de tentar transmiti -lo ao DAL e, assim, tornar o relatório de erro mais centrado no objeto de domínio.Eu acho que você poderia argumentar que eu poderia apenas verificar a restrição no meu construtor e no setter de propriedades, mas como tenho centenas de classes que têm restrições semelhantes, eu queria uma maneira mais genérica de resolver o problema

Agora, o que eu criei é uma classe chamada ConstrainedString, definido da seguinte forma:

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;
        } 
    }
}

Além disso, tenho uma implementação de ConstrainedString chamado String100 :

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

Levando assim a uma implementação diferente de Case ficaria assim:

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; }
}

Agora, minha pergunta é;Estou negligenciando algumas classes internas ou alguma outra abordagem que eu poderia usar?Ou esta é uma abordagem razoável?

Quaisquer comentários e sugestões são bem-vindos.

Agradeço antecipadamente

Answer 1

Acredito que sua validação deva residir no seu modelo de domínio.As restrições nos seus campos representam diretamente alguma lógica de negócios.Em última análise, você precisa validar antes de persistir.

Answer 2

Eu acho que isso depende de muitos fatores (assim como de algumas preferências pessoais). Às vezes, a restrição deve fazer parte do objeto de domínio - por exemplo, com números de seguridade social/passaporte ... - normalmente têm um comprimento fixo e não podem variar como uma regra de domínio - não uma regra de persistência de dados (embora você possa restringir o banco de dados também).

Alguns preferem não ter esse tipo de verificação em seu modelo de domínio e, em vez disso, têm algo como um atributo de validação na propriedade que pode ser inspecionada e executada externa do objeto de domínio por um validador separado.

O problema que você pode ter com o seu método (embora não seja difícil de se locomover) é obter qualquer ORM/Mapper - se você estiver usando um - para saber como mapear uma string de/para o banco de dados para o seu restrito.

A história restrita pode não contornar a questão do objeto de domínio com informações extras sobre a restrição, pois pode precisar construir o restrito da história

Answer 3

Se você alterar as restrições de um caso, faz sentido que você tenha que criar um novo - você mudou o contrato e o código antigo não saberá mais se está atendendo aos requisitos ou não.

Em vez de se preocupar com o que seu repositório permitirá ou não, defina o que vocês Permitirá em sua classe e certifique -se de encontrar uma maneira de trabalhar com qualquer repositório para o qual você mude no futuro. Você possui sua API - suas dependências não.