Иногда перед разработчиками встает задача использования JSON-полей в Entity Framework Core. Традиционный подход с использованием Fluent API требует написания дополнительного кода, что может усложнить проект. Пакет JsonProperty.EFCore решает эту проблему. Эта статья расскажет о пользе JsonProperty.EFCore и о том, как он упрощает работу с JSON-полями, что делает его удобным инструментом для разработчиков.
Проблема: Сложное управление JSON-полями
Entity Framework Core отлично поддерживает работу с реляционными базами данных, но управление JSON-полями может стать непростой задачей. Настройка Fluent API для отображения JSON-полей на свойства сущностей требует написания дополнительного кода, что может увеличить сложность проекта. С учетом возникающей иногда необходимости хранить данные в формате JSON разработчикам необходимо эффективное решение для интеграции JSON-полей в модели EF Core.
JsonProperty.EFCore: Упрощенный подход
JsonProperty.EFCore предлагает новое решение для управления JSON-полями. Он позволяет использовать JSON-поля в EF Core без необходимости настройки сложного Fluent API. Благодаря этому открытому проекту NuGet, разработчики могут упростить свой рабочий процесс и сосредоточиться на создании логики приложения, минуя сложные настройки EF Core.
Особенности и преимущества
Простая интеграция: JsonProperty.EFCore предлагает простой процесс интеграции. Разработчики просто добавляют пакет, указывают директиву
using
и создают модель сущности, как обычно - не требуется дополнительная настройка для JSON-полей.Поддержка обобщенных типов: Пакет поддерживает обобщенные типы, такие как
JsonEnumerable<T>
иJsonDictionary<TKey, TValue>
, что позволяет разработчикам работать с пользовательскими типами элементов в коллекциях JSON без усилий.Безупречное управление JSON: С JsonProperty.EFCore управление JSON-полями становится намного проще. Разработчики могут непосредственно добавлять свойства типов
JsonEnumerable
,JsonList
,JsonDictionary
илиJsonItem
в свои модели сущностей и легко управлять JSON-полями.Строгая сериализация типов: Пакет позволяет разработчикам включить строгую сериализацию типов. При включении типы данных включаются в JSON, обеспечивая повышенную целостность и последовательность преобразования данных.
Полиморфизм: строгая типизация позволяет сохранить полиморфные типы при сериализации и десериализации в JSON.
Примеры использования
Давайте рассмотрим несколько примеров использования JsonProperty.EFCore, чтобы продемонстрировать его полезность и удобство:
-
Хранение параметров продукта:
Допустим, у нас есть сущность "Product" с различными параметрами, сохраняемыми в JSON-полях. С JsonProperty.EFCore добавление и управление этими параметрами становится невероятно простым:
public class Product { public int Id { get; set; } public string Name { get; set; } public JsonDictionary Parameters { get; set; } = new(); }
Запись
JsonDictionary
аналогичнаJsonDictionary<string, object>
. При этом полиморфизм позволяет хранить значения любых типов в таком словаре.А вот пример управления коллекцией
JsonDictionary
:Product product = new() {Name="Phone",Price=500.95m,Amount=21,Parameters={ VirtualDictionary = new Dictionary<string,object>() { {"Camera",13.5 },{"OS","Android" },{"Screen","1080x900"},{"Storage",32} } }}; db.Goods.Add(product); db.SaveChanges();
Это сгенерирует следующие данные для поля в формате JSON, если настройка
JsonSettings.StrictTypeSerialization
имеет значениеtrue
(по умолчанию):{ "Camera": [13.5, "System.Double"], "OS": ["Android", "System.String"], "Screen": ["1080x900", "System.String"], "Storage": [32, "System.Int32"] }
Также можно добавлять и редактировать элементы поля
JsonDictionary
:Product product = db.Goods.FirstOrDefault(); product.Parameters.Add("Battery capacity", 3000); product.Parameters.Edit(dict => { dict["Battery capacity"] = 4000; dict["Storage"] = 64; dict.Add("RAM", 4); return dict; });
После этого JSON-поле примет следующий вид:
{ "Camera": [13.5, "System.Double"], "OS": ["Android", "System.String"], "Screen": ["1080x900", "System.String"], "Storage": [64, "System.Int32"], "Battery capacity": [4000, "System.Int32"], "RAM": [4, "System.Int32"] }
-
Управление элементами списка дел:
Предположим, у нас есть сущность "Note" с коллекцией элементов "TodoItem", сохраняемых в JSON. JsonProperty.EFCore облегчает работу с коллекциями JSON:
public class Note { public int Id { get; set; } public string Header { get; set; } public JsonList<TodoItem> Todos { get; set; } = new(); }
При этом в списке
JsonList<TodoItem>
можно также хранить элементы с типом, наследуемым отTodoItem
. -
Простое добавление полиморфного поля:
Допустим, нам надо добавить в нашу сущность поле с абстрактным или просто полиморфным типом, без организации сложной системы сущностей и таблиц для наследуемых типов. Здесь отлично поможет JsonProperty.EFCore:
using JsonProperty.EFCore; class MyEntity { public int Id { get; set; } public int Title { get; set; } public JsonItem<Base> Content { get; set; } = new(); }
Теперь можно использовать полиморфное поле:
MyEntity myEntity = new(); myEntity.Content.Serialize(new DerivedType1()); Base val = myEntity.Content.Deserialize(); Console.WriteLine(val is DerivedType1); //true
Заключение
JsonProperty.EFCore - это ценный открытый проект, который упрощает управление JSON-полями в Entity Framework Core. Избавляя от необходимости настройки Fluent API, он дает возможность разработчикам проще работать с JSON-полями, обеспечивая простоту и эффективность разработки. Простая интеграция, поддержка обобщенных типов и полиморфизм делают JsonProperty.EFCore полезным инструментом для разработчиков приложений.
Если вы хотите упростить управление JSON-полями в EF Core, попробуйте JsonProperty.EFCore. Посетите репозиторий на GitHub, чтобы узнать больше и оценить проект. Удачной разработки!
Комментарии (15)
Heggi
06.08.2023 16:02+1EFCore прекрасно поддерживает json поля без всяких сторонних библиотек и fluent api. Нужно просто правильно описать модельки.
Проверял на PostgreSQL и MySQL
maxchistt Автор
06.08.2023 16:02Ну, во-первых, нет, без fluent api, на данный момент, в .net 7, невозможно настроить конвертацию в json. Во-вторых, придется постараться, чтобы json-поля поддерживали полиморфизм с точным преобразованием типов.
Heggi
06.08.2023 16:02Мы видимо про разное?
Я на модельке просто делаю вот так и мои потребности закрывает.[Column(TypeName = "jsonb")]
public Dictionary<string, string> Details { get; set; } = new();
Или так:[Column("additional", TypeName = "json")] public MetaObject? Meta { get; set; } public class MetaObject { [JsonPropertyName("service")] public string Service { get; set; } = string.Empty; [JsonPropertyName("payout")] [JsonNumberHandling(JsonNumberHandling.AllowReadingFromString)] public decimal Payout { get; set; }
}P.S. как тут код нормально отформатировать???
maxchistt Автор
06.08.2023 16:02-1По крайней мере, с mssql такая запись не сработает. Может, вы не указали какие-то детали.
Даже если в некоторых условиях такая запись сработает, она всё-же не будет поддерживать полиморфизм.
P.S. для форматирования кода, поместите его в тройные косые кавычки (не знаю, как правильно назвать такие кавычки): " ``` "
Heggi
06.08.2023 16:02С mssql не работал, там не знаю.
Для полиморфизма (точнее для чтения raw json, а потом что хочешь с ним, то и делай) у драйверов pgsql и mysql есть соответствующие типы, которые можно подставить в модельку.
s207883
06.08.2023 16:02record Sample ();
Heggi
06.08.2023 16:02[Column("additional", TypeName = "json")] public MetaObject? Meta { get; set; } public class MetaObject { [JsonPropertyName("service")] public string Service { get; set; } = string.Empty; [JsonPropertyName("payout")] [JsonNumberHandling(JsonNumberHandling.AllowReadingFromString)] public decimal Payout { get; set; } }
У меня почему-то другой интерфейс, но разобрался.
granit1986
Не очень понял в чём отличие от хранения обычной строки и преобразовании в объект через HasConversation()?
maxchistt Автор
Во-первых, это более простая в использовании, более наглядная и удобная альтернатива HasConversation(), вообще не требующая использовать Fluent API. Во вторых, тут доступна строгая сериализация, в том числе позволяющая поддерживать полиморфизм для сложных пользовательских классов, а не только базовых типов. Конечно, можно это реализовать и через Fluent API, но тогда будет еще больше лишнего кода, а тут готовый удобный функционал.
hello_my_name_is_dany
Две строчки кода, которые позволяют вообще не думать в большинстве случаев из-за использования проверенных временем сериализаторов, выглядят не так уж и плохо, чем работа с непонятным API, который к тому же будет просачиваться везде, потому что становится частью модели
maxchistt Автор
Это будет не две строчки кода, если вам нужно поле типа List<object>, в котором значения типа int, double и decimal, инициализированные литералом "1", будут десериализованы при получении из бд как int , double и decimal, а не как int64 все трое. Или если вам нужно, чтобы поле типа BaseType десериализовалось как ChildType, если туда был записан объект такого типа.
hello_my_name_is_dany
Всё подводить к object вообще глупо из-за боксинга, который далеко не бесплатный, да и разнародный список уже говорит о том, что лучше уж сделать класс с полями/свойствами, чем поддерживать непонятно что, каждый раз думая, а что же там храниться
hVostt
Когда вы добавляете внешнюю зависимость в проект в виде сторонней библиотеки — это уже само по себе рискованно и не очень хорошо:
Зависимость это ещё одна дополнительная точка, которую постоянно, при обновлениях, потребуется проверять на уязвимость.
Большинство разработчиков не имеют никакого опыта работы с большинством сторонних библиотек. Значит это дополнительная когнитивная нагрузка, усложнение дальнейшего развития и сопровождения, особенно когда зависимость просачивается в контракты и модели (вот это совсем плохо).
Частенько, сторонние библиотеки перестают поддерживаться, и придётся переходить на форки.
Это не всё, конечно, но достаточно, чтоб не тащить в проект абсолютно любую фигню, чтобы сократить пару строк.
Если вы добавляете себе в проект зависимость, плюсы должны перевешивать все минусы. Это действительно должно быть решение, которое здорово облегчит вам жизнь и вы готовы мириться со всеми рисками.
Решение, которое вы описали к таковым, как мне кажется, не относится. Его можно изучить и даже кое что взять на вооружение, но задача решается "из коробки" — и вот этому стоило посвятить статью.
Как сложить 2+2? Берём библиотеку TwoPlusTwo и вуаля! Не надо так :)
maxchistt Автор
Как минимум, задача записать в json-поле типа BaseType объект типа ChildType, а затем десериализовать значение именно последнего типа, не решается "из коробки" в EF
hVostt
Не буду прям утверждать хорошо это или плохо, но я бы таки настоятельно советовал избегать наследования при сериализации/десериализации в JSON. Никаких стандартов на эту тему нет, а наследование в перспективе начнёт приносить всё меньше каких-либо выгод, и всё больше боли и страданий.