Почему Entity Framework создает сущности как частичные классы?

Другие ORM, которые я использовал, такие как Torque, Propel или Doctrine, генерируют 2 класса для каждой сущности: например, BaseCustomer и Customer. Customer наследуется от BaseCustomer, и вы можете переопределить методы или добавить свои собственные.

Но Entity Framework генерирует частичные классы. Вы можете добавлять методы, но не переопределять их (методы-конструкторы или методы доступа).

Это почему?

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

разве это не недостаток EF, ограничивающий свободу разработчиков?


entity-framework orm entity-framework-4 partial-classes
person Psycho42    schedule 15.06.2011    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Генерация кода по умолчанию для EF выполняется как есть. Вы не можете изменить прямое поведение. Вы можете добавить свое собственное поведение только в разделяемые классы. С конструктором проблем нет, потому что, насколько я знаю, EF не создает конструктор для сущностей — он использует конструктор по умолчанию.

В EF 4 все это сильно изменилось. Вы можете отключить генератор сущностей по умолчанию и вместо этого использовать шаблон T4. Шаблон T4 — это просто еще один файл сценария, который вы можете изменить и добавить любые необходимые вам изменения.

Если вам нужно лучшее объяснение, почему это делается таким образом, вы должны спросить команду ADO.NET, но обычно частичные классы являются распространенным способом работы с сгенерированным кодом во всей среде .NET, поэтому они, вероятно, сохраняют его для согласованности.

person Ladislav Mrnka    schedule 15.06.2011

arrow_upward
2
arrow_downward

Наследованием обычно злоупотребляют, и на самом деле оно ограничивает не только частичные классы. В качестве принципа проектирования классы должны быть открыты для расширения, и частичные классы делают это лучше, чем унаследованные классы.

Что касается переопределения свойств/методов автоматизированных объектов, вы всегда можете использовать новое ключевое слово (если вы используете C#):

public MyCustomer : Customerbase {
    public new string FirstName { ... }
}

Однако любой класс, наследующий от MyCustomer, по умолчанию вернется к FirstName от Customer.

person bitxwise    schedule 15.06.2011

arrow_upward
0
arrow_downward

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

Я полагаю, что все дизайнерские решения имеют компромиссы — я работал с Propel, и в этом контексте мне также нравится его модель. Тем не менее, EF, похоже, хорошо соответствует парадигме .NET, и я нашел частичные классы «достаточно хорошими» для расширения сущностей, когда мне это нужно.

person Andrew    schedule 15.06.2011