.NET ORM, объекты с неизменяемыми значениями, структуры, конструкторы по умолчанию и свойства только для чтения - PullRequest
Новая
       41

.NET ORM, объекты с неизменяемыми значениями, структуры, конструкторы по умолчанию и свойства только для чтения

7 голосов
/ 19 марта 2011

Я только начинаю работать с .NET ORM, и до такой степени, что я даже не определился между Entity Framework и NHibernate.Но в обоих случаях я сталкиваюсь с проблемой, заключающейся в том, что они, похоже, хотят, чтобы я нарушил целостность моей предметной модели различными способами, особенно в отношении более тонких аспектов проектирования объектов C #.Это один из нескольких вопросов по этому вопросу.

Я очень привык применять неизменность для соответствующих свойств с помощью шаблона, который выглядит следующим образом: 

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

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

Это не отображаетсяподдерживаться NHibernate или Entity Framework.Им нужны конструкторы по умолчанию и сеттеры public;кажется, даже private сеттеры (и конструкторы по умолчанию) работают (иногда?), потому что ORM могут использовать отражение.

Полагаю, я могу обойти их, используя private сеттеры и private конструктор по умолчанию,По крайней мере, тогда публичный API не будет скомпрометирован.Просто я изменяю все реализации моих классов, чтобы добавить неиспользуемые private конструкторы, и необходимость доверять будущему Domenic, потому что он понимает private в моих установщиках, действительно означает "не вызывайте меня, кроме как в конструкторе"."Слой персистентности просачивается в мой объектный дизайн.

Это также просто кажется ненужным - почему ORM не может знать, что используется конструктор не по умолчанию?Может быть, они в состоянии, и я просто не нашел нужную запись в блоге, объясняющую, как.

Наконец, в некоторых случаях мои неизменяемые значения объектов действительно подходят (неизменяемые) значения типов , то есть struct с.Я предполагаю, что это возможно, поскольку в базе данных поля моей структуры будут отображаться в той же строке, что и родительский объект.Вы можете подтвердить / опровергнуть? Этот пост в блоге выглядит многообещающе в том смысле, что он дает утвердительный ответ, но объем кода (который на самом деле специфичен для рассматриваемого типа значения) поражает воображение.

Вызывает разочарование тот факт, что после нескольких лет чтения книг, таких как Effective C # , или блогов, подобных тем, что пишут Эрик Липперт, которые дают отличный совет о том, как создавать выразительные и пуленепробиваемые объекты C #, необходимость использовать ORM заставляет меня бросать многоэтого знания из окна.Я надеюсь, что кто-то здесь может указать, где я не прав, либо в моём понимании их возможностей, либо в моих мыслях о моделировании предметной области и роли ORM.

1 Ответ

1 голос
/ 08 апреля 2011

Как отмечают комментарии, вам придется пойти на некоторые компромиссы, когда / если вы примете ORM. На мой взгляд, следует помнить, что прирост производительности намного перевешивает «издержки» этих компромиссов.

Я хотел бы указать вам (поскольку вы новичок в EF), что вы можете настроить шаблоны T4 , которые генерируют сущности и контексты EF. Я думаю, что если вы поиграете с этим, вы сможете сгладить большинство вещей, которые вам не нравятся.

...