Estou apenas começando com o .NET ORMs, a ponto de ainda não ter decidido entre o Entity Framework e o NHibernate. Mas, em ambos os casos, estou com um problema, pois eles parecem querer que eu comprometa a integridade do meu modelo de domínio de várias maneiras, especialmente em pontos mais delicados do design de objetos em C #. Essa é uma das várias perguntas sobre o assunt

Estou muito acostumado a reforçar a imutabilidade em propriedades apropriadas com um padrão semelhante a este:

public class Foo
{
    private readonly string bar;
    public string Bar { return this.bar; }

    public Foo(string bar)
    {
        this.bar = bar;
    }
}

@This não parece ser suportado pelo NHibernate ou Entity Framework. Eles querem construtores padrão epublic setters; parece atéprivateetters (e construtores padrão) funcionam (às vezes?) porque os ORMs podem usar reflexã

Suponho que posso contornar esses problemas usandoprivate setters e umprivate construtor padrão. Pelo menos a API pública não está comprometida. Estou apenas modificando todas as implementações de minhas classes para adicionar @ não utilizadprivate construtores, e ter que confiar no futuro-Domenic que ele entendeprivate nos meus levantadores realmente significa "não me ligue, exceto no construtor". A camada de persistência está vazando para o design do meu objeto de domíni

Também parece desnecessário --- por que o ORM não pode saber usar o construtor não padrão? Talvez eles consigam, e eu simplesmente não encontrei o post certo explicando com

Finalmente, em alguns casos, meu objetos de valor imutável realmente se encaixam bem como (imutáveis)tipos de valores, ou seja,structs. Meu palpite é que isso é possível, pois no banco de dados os campos da minha estrutura aparecerão na mesma linha em que a entidade pai está armazenada. Você pode confirmar / negar?Esta publicação no blog parece promissor, pois fornece uma resposta afirmativa, mas a quantidade de código (que é de fato específica ao tipo de valor em questão) surpreende a ment

É frustrante que, depois de vários anos lendo livros comoEffective C # ou blogs como o de Eric Lippert, que dão ótimos conselhos sobre como criar objetos C # expressivos e à prova de balas, a necessidade de usar ORMs está me fazendo jogar muito desse conhecimento pela janela. Espero que alguém aqui possa apontar onde estou errado, seja ao entender suas capacidades ou ao pensar sobre modelagem de domínio e o papel das ORM