Почему NHibernate требует "защищенной внутренней" видимости для автоматических свойств?

#c# #nhibernate

Вопрос:

Раньше было возможно сопоставлять автоматические свойства с частными настройщиками с помощью NHibernate, но начиная с версии 3.2 это больше не так (не без замены средства проверки сущности), см. Обсуждение NH dev.

Я понимаю protected требование, но почему internal ? Это нарушает инкапсуляцию и просто кажется грязным.

Является ли единственной альтернативой возврат к резервным полям?

ОБНОВЛЕНИЕ: смущающее, но верное, оказывается internal , не требуется. Итак, это выбор между возвратом к резервным полям или использованием защищенного установщика и либо избеганием установки значений в конструкторе, либо риском появления трудно отслеживаемых ошибок. Спасибо Fabio и @Nexus за указание на мою ошибку.

1. вы имели в виду «почему virtual » вместо «почему internal «?

2. нет, я имел в виду почему, protected internal а не просто protected , если я не могу иметь private .

3. хорошо, меня ввело в заблуждение оригинальное название…

Ответ №1:

Майкл,

public string Foo { get; protected set; } все еще должно быть возможно, обсуждение разработчиков касается public string Foo { get; private set; } того, что может привести к ошибкам при использовании отложенных свойств.

1. Средство проверки прокси использует MethodBase. IsFamilyOrAssembly, поэтому internal ИЛИ protected должны работать, но я не думаю, что для этого нужны оба.

2. Я почти уверен, что я это тестировал, но если вы правы, это было бы ошибкой. Приводит к некоторому.

3. Протестировано и обновило вопрос с результатами (вы были правы, спасибо!)

Ответ №2:

NHibernate довольно грязный. Он использует отражение для доступа к свойствам и полям.

Вы даже можете отображать private свойства и поля как точки данных.

NHibernate полностью игнорирует видимость элементов, к которым ему необходимо получить доступ.

1. Пауло, как бы ты сопоставил это с NH 3.2: public string Foo { get; private set; } ?

2. Я совершенно не помню код NHbiernate, который запрашивает средство получения и установки свойства. Это можно было бы сделать, но я не уверен.

Ответ №3:

 public class Class{

    public string Foo { get; private set; }

}

Property(class=> class.Foo);

Затем вам нужно будет отключить проверку прокси-сервера в вашей конфигурации:

Config.Proxy(p => {p.Validation = false});