Acabo de comenzar con .NET ORM, hasta el punto de que ni siquiera he decidido entre Entity Framework y NHibernate. Pero en ambos casos, me encuentro con un problema en el sentido de que parecen querer comprometer la integridad de mi modelo de dominio de varias maneras, especialmente en puntos más finos del diseño de objetos de C #. Esta es una de varias preguntas sobre el tema.

Estoy muy acostumbrado a imponer la inmutabilidad en las propiedades apropiadas con un patrón que se ve así:

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

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

Esto no parece ser compatible con NHibernate o Entity Framework. Quieren constructores predeterminados ypublic setters; parece inclusoprivate setters (y constructores predeterminados) funcionan (¿a veces?) porque los ORM pueden usar la reflexión.

Supongo que puedo evitar esto usandoprivate setters y unprivate Constructor predeterminado. Al menos, la API pública no se ve comprometida. Es solo que estoy modificando todas las implementaciones de mis clases para agregar @ sin usprivate constructores, y tener que confiar en el futuro-Domenic que él entiendeprivate en mis setters realmente significa "no me llames excepto en el constructor". La capa de persistencia se está filtrando en mi diseño de objeto de dominio.

También parece innecesario --- ¿por qué el ORM no puede saber usar el constructor no predeterminado? Tal vez puedan, y simplemente no encontré la publicación de blog correcta explicando cómo.

Finalmente, en algunos casos mi objetos de valor inmutable realmente se ajusta bien como (inmutable)value types, es decir,structs. Supongo que esto es posible, ya que en la base de datos los campos de mi estructura se mostrarán en la misma fila en que se almacena la entidad principal. ¿Puedes confirmar / negar? @Esta publicación de blog parece prometedor porque da una respuesta afirmativa, pero la cantidad de código (que de hecho es específica para el tipo de valor en cuestión) escalona la mente.

Es frustrante que después de varios años leyendo libros comoEfectivo C # o blogs como los de Eric Lippert, que brindan excelentes consejos sobre cómo diseñar objetos C # expresivos y a prueba de balas, la necesidad de usar ORM me está haciendo arrojar gran parte de ese conocimiento por la ventana. Espero que alguien aquí pueda señalar dónde estoy equivocado, ya sea en mi comprensión de sus capacidades o en mi pensamiento sobre el modelado de dominios y el papel de los ORM.