Я действительно хочу иметь возможность использовать NodaTime в проектах Entity Framework Code First Database, но не нашел "чистого" способа сделать это. Я действительно хочу это сделать:
public class Photoshoot
{
public Guid PhotoshootId{get; set;}
public LocalDate ShootDate{get; set;} //ef ignores this property
}
Есть ли поддерживаемый или рекомендуемый подход к использованию NodaTime с EF Code First?
До тех пор, пока в Entity Framework не поддерживается постоянное сохранение примитивного типа, общая работа заключается в использовании свойств друзей.
Для каждого пользовательского примитива в вашей модели домена вы создаете связанный сопоставленный примитив для хранения значения в формате, поддерживаемом Entity Framework. Пользовательские примитивные свойства затем вычисляются из значения их соответствующего свойства собеседника.
Например:
public class Photoshoot
{
// mapped
public Guid PhotoshootId{get; set;}
// mapped buddy property to ShootDate
public DateTime ShootDateValue { get; set; }
// non-mapped domain properties
public LocalDate ShootDate
{
get { // calculate from buddy property }
set { // set the buddy property }
}
}
Мы используем NodaTime в нашем коде сначала POCO, используя именно этот подход.
Очевидно, это оставляет вас одним типом, действующим как код первого POCO, так и тип домена. Это можно улучшить за счет сложности, разделив различные обязанности на два типа и сопоставление между ними. Альтернативой на полпути является продвижение свойств домена в подтип и защита всех свойств сопоставленных друзей. С определенным количеством Wanging Entity Framework можно сделать карту для защищенных свойств.
Это довольно великолепное сообщение в блоге оценивает поддержку Entity Framework для различных конструкций моделирования домена, включая инкапсулированные примитивы. Именно здесь я впервые нашел концепцию свойств приятеля при создании наших POCO: http://lostechies.com/jimmybogard/2014/04/29/domain-modeling-with-entity-framework-scorecard/
В другом блоге в этой серии обсуждается сопоставление с защищенными свойствами: http://lostechies.com/jimmybogard/2014/05/09/missing-ef-feature-workarounds-encapsulated-collections/
Нет "чистого" способа, о котором я знаю, поскольку EF, на момент написания этой статьи, не имеет механизма для простого преобразования типов как вы видите в NHibernate (IUserType). Реальное ограничение в EF как ORM, которое заставляет меня изменять свой домен в соответствии с моим ORM.