Свободное отображение частных полей NHibernate

Question

Свободное отображение частных полей NHibernate

1

Я создал некоторый свободный код NHibernate. Он имеет код сущности:

    private ISet<CardPlace> _cardPlace;

    public MagazineType()
    {
        _cardPlace = new HashedSet<CardPlace>();
    }

    public virtual ISet<CardPlace> CardPlace
    {
        get { return _cardPlace; }
        set { _cardPlace = value; }
    }

И отображение для этого свойства:

       HasMany(x => x.CardPlace)
            .Access.CamelCaseField(Prefix.Underscore)
            .Cascade.AllDeleteOrphan()
            .Fetch.Select()
            .AsSet()
            .Inverse()
            .LazyLoad()
            .KeyColumns.Add("MAGAZINE_ID");

Я не понимаю, это .Access.CamelCaseField(Prefix.Underscore). Почему это не сопоставляется непосредственно с собственностью, а вместо этого сопоставляется с частным полем поддержки? Есть ли причина для этого?

Cemre 22 май 2014, в 15:25

Источник

Теги:

c#

nhibernate

fluent-nhibernate

2 ответа

Ещё вопросы

Radim Köhler · Answer 1 · 2014-05-23T03-54-00.000Z

Ответ здесь был/должен/мог бы быть: улучшить дизайн модели домена. Главным вспомогательным словом здесь будет "инкапсуляция". Потому как:

Почему мы пытаемся создать нашу твердую модель (со всеми правилами ведения бизнеса/проверки)...
... при открытии задней двери, т.е. имеющей публичные сеттеры.

Есть действительно хорошая статья, очень углубляясь в это:

Укрепление домена: избегайте настройки

Позвольте мне привести, только из его Резюме (но, пожалуйста, пройдите через этот текст)

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

И все аргументы из статьи (прочитайте это пожалуйста), сжатые в последнем абзаце:

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

ПРИМЕЧАНИЕ. Ну, я использую публичные сеттеры, и я использую "оправдания" вроде "лучше тестировать...

nuno · Answer 2 · 2014-05-22T10-57-00.000Z

Если вы удалите

.Access.CamelCaseField(Prefix.Underscore)

отображение будет состоять из свойства getter и setter.

Эта строка инструктирует беглого nhiberate использовать поле вместо этого.

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