Несколько вопросов о nhibernate и свободно nhibernate

Question

У меня есть пара вопросов.

1. Я читал в руководстве для начинающих nhibernate № 3 об использовании автоматического картографирования с свободное владение. Я читал об этом раньше (и я уже использую auto mapper в своем проекте), однако я все еще не уверен насчет пары вещей.

Что происходит, когда вам нужно поставить как Not.Null (), или нужно установить длину, или инвертировать что-то. Как вы их настраиваете? Вам не нужно будет настраивать автоматическое сопоставление для каждого из этих свойств, которые имеют эти настройки? Разве это не по умолчанию цель?

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

Прочитав это, я задаюсь вопросом, имеет ли смысл иметь 2 отображения этих классов, которые мне нужно прочитать только

Скажи, что у меня есть

   public PlanMap()
        {
            Table("Plans");
            Id(x => x.Id);

            Map(x => x.Name).Not.Nullable().NvarcharWithMaxSize();
            Map(x => x.Description).Not.Nullable().NvarcharWithMaxSize();
            Map(x => x.Price).Not.Nullable();
            Map(x => x.Discount).Not.Nullable();
            Map(x => x.LengthInMonths).Not.Nullable();

            References(x => x.Role).Not.Nullable();
            HasMany(x => x.Students).Cascade.All();

        }

Так было бы разумно иметь это, а затем иметь

    public ReadOnlyPlanMap()
    {
        Table("Plans");


        ReadOnly();
        SchemaAction.None();


        Id(x => x.Id);
        Map(x => x.Name).Not.Nullable().NvarcharWithMaxSize();
        Map(x => x.Description).Not.Nullable().NvarcharWithMaxSize();
        Map(x => x.Price).Not.Nullable();
        Map(x => x.Discount).Not.Nullable();
        Map(x => x.LengthInMonths).Not.Nullable();

        References(x => x.Role).Not.Nullable();
        HasMany(x => x.Students).Cascade.All();

    }

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

3. Я прочитал в книге, что он рекомендует не использовать опцию «автоматического» увеличения в вашей базе данных, а вместо этого использовать настройку hi-lo one в nhibernate для этого.

В книге говорится, что если бы вы сделали что-то вроде session.Save(object);, то на самом деле он пошел бы и связался с сервером, и это сломало бы единицу работы. Это происходит, когда в базе данных установлено «автоматическое» приращение? Я никогда не видел доказательств того, что это произошло, и на самом деле мне нужно было сделать запись, прежде чем я смог увидеть удостоверение личности.

Когда вы используете hi-lo, каким типом данных должен быть ваш столбец? Я обычно использую для моего ПК инкрементный int. Могу ли я использовать int?

1. Наконец, из множества примеров, которые я видел, они обычно делают свои свойства PK такими, как эта

   public virtual int Id { get; private set; }
   

Все же в книге я постоянно видел

    public virtual int Id { get; set; }

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

Answer 1

Если бы вы разбили их на отдельные вопросы, вам бы повезло, если бы вы ответили на все ваши вопросы, но я все равно рассмотрю пару ваших вопросов:

Автоматическое сопоставление, Пользовательские соглашения иПереопределения

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

Затем, если у вас есть отображение, которое должно немного отличаться от ваших соглашений, то вы можете обеспечить автоматическое переопределение, реализуяIAutoMappingOverride<T> где вы указываете только те столбцы / идентификаторы / отношения, которые являются аберрантными для соглашений.

Документация на вики FluentNHibernate на Переопределяет и Условные обозначения - этона самом деле очень хорошо, я настоятельно рекомендую прочитать его.

Только для чтения сущностей

Если бы я делал это, то я бы проигнорировал NHibernate, internal setсвойство называется что-то вроде IsReadonly { get; internal set; }, когда объект извлекается откуда-то, что он должен быть доступен только для чтения, затем установите это свойство перед возвратом его вызывающей стороне.

Если у вас есть явный метод Save дляхранилище, вы можете проверить это свойство и не делать реальное сохранение NHibernate, если оно true.Если вы полагаетесь на грязную проверку NHibernate для сохранения в сеансе Flush, то вы можете реализовать прослушиватель NHibernate, который не будет сохранять сущность, если это свойство будет true.

Идентификаторы

Одно слово (акроним) GUID;Привет-ло может работать, но это может быть сложным и немного привередливым.Чтобы NHibernate правильно отслеживал объект, он должен иметь уникальный идентификатор.Если вы используете автоматические идентификаторы, то NHibernate будет отправляться в базу данных, чтобы получить идентификатор, когда вы Save вашей сущности, и прежде чем вы Flush.

Comb GUID решаютпроблемы, с которыми вы столкнетесь при использовании автоматических идентификаторов и hi-lo в обмен на то, что занимает немного больше места в вашей БД и памятиПри использовании автоматического картирования FluentNHibernate, если ваша сущность имеет GUID в качестве типа своего свойства Id, она будет автоматически использовать стратегию Guid Comb .