CustomType для ссылок с FluentNHibernate - PullRequest
Новая
       16

CustomType для ссылок с FluentNHibernate

0 голосов
/ 18 февраля 2019

Я использую библиотеку под названием LanguageExt .Эта библиотека предоставляет некоторые инструменты для обработки функционального программирования в коде C #.Я также использую FluentNHibernate для сопоставления классов моего домена с моей базой данных.

Когда свойство обнуляется, я хочу использовать Option<T> из LanguageExt.Это структура, которая либо содержит значение, либо равна None.

Одна из моих моделей классов, скажем, Car, имеет необязательное свойство, скажем, Sunroof, тип Option<Window>.Например: 

public class Car
{
   Window _sunroof;
   Option<Window> Sunroof
   {
     get => Optional(_sunroof);
     set => _sunroof = value.IfNoneUnsafe(() => null);
   }
}

Мое сопоставление выглядит следующим образом: 

References<Window>(x => x.Sunroof, "idSunroof")
   .Not.Nullable();

Мой вопрос: как мне отобразить свойство Sunroof, используя его поле поддержки, зная, что они не разделяюттот же тип возврата?

Ответы [ 2 ]

0 голосов
/ 09 апреля 2019

Я наконец нашел решение: 

References(x => x.Sunroof, "idSunroof")
    .Access.CamelCaseField(Prefix.Underscore)
    .Class<Window>();
0 голосов
/ 19 февраля 2019

Это модель домена, но она также сопоставлена ​​с некоторой таблицей в базе данных с помощью конфигурации сопоставления, выполненной FluentNHibernate.

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

Я рекомендую иметь DTO для NHibernate (возможно, называется CarDto) и бизнес-модель (вероятно, называется Car).Таким образом, CarDto может измениться по причинам, связанным с базой данных (но не по причинам моделирования), а Car может измениться по причинам моделирования (но не по причинам базы данных).Например, функциональное программирование должно иметь неизменную бизнес-модель, но NHibernate может потребовать, чтобы его DTO были изменяемыми.Если вы используете один и тот же тип для обеих целей, вы не сможете удовлетворить все ограничения проекта.

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

Не думаю, что у вас должно быть свойство и вспомогательное поле с разными типами.С CarDto используйте null для представления отсутствия Window.Затем при отображении из CarDto в Car отобразите null в состояние None (с помощью функции Optional, которую вы используете в данный момент).Затем при отображении с Car на CarDto отобразите None обратно на null (с помощью метода IfNoneUnsafe, который вы используете в настоящее время).

Ваш Car класс

  1. - это DTO NHibernate,
  2. - ваша бизнес-модель,
  3. содержит отображение из DTO в бизнес-модель, а
  4. содержит отображение из бизнесамодель для DTO.

Это три или четыре вещи (в зависимости от того, считаете ли вы отображение как одно или два), которые я упомянул выше.

ДОБАВЛЕНО2019-02-20

[ваш ответ] не решение моей проблемы, а предложение по улучшению архитектуры

Это и то и другое.

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

Я не предлагаю вам изменить все сразу.Отнюдь не.В стиле Refactoring от Martin Fowler, я рекомендую вносить много небольших изменений со временем.

Например, насколько трудно будет изменить Car на 

public class Car
{
   Option<Window> Sunroof
   {
     get => Optional(SunroofBacking);
     set => SunroofBacking = value.IfNoneUnsafe((Window) null);
   }
   Window SunroofBacking { get; set; }
}

и использовать («лучше» названное) свойство Sunroof для целей бизнес-логики и использовать SunroofBacking для NHibernate причин?

...