И не только сериализаторы. При проекции данных из БД в объекты при помощи Dapper можно получить схожий сценарий, если значения целочисленного поля в БД не соответствуют значениям в перечислении. В т.ч. можно получить enum-свойство, значение которого вовсе отсутствует в перечислении.
Если отдавать генерацию на сторону клиента, то это порождает сценарии, которые сложно контролировать.
Требуется как-то заставить всех внешних пользователей вашего API применять строго определённую схему генерации условно-последовательных GUID, которые будут наилучшим образом подходить для конкретного используемого хранилища. Например, у MSSQL свой подход к сортировке кластеризованных PK типа 'uniqueidentifier' (по части байтов). У другой БД может быть другой подход. А если разные сущности хранятся в хранилищах разного типа, то для каждой сущности придётся описывать свой тип генерации ID. А если использовать полностью случайные GUID, то это может порождать описанные в начале статьи проблемы с производительностью хранилища.
При этом сервер не имеет возможности как-то контролировать корректность генерации, т.е. мы вынуждены верить клиенту. А если такую возможность и реализовать (под конкретный тип хранилища), то она всё равно будет работать с определёнными допущениями, т.к. для генерации последовательного ID в любом случае придётся применять системное время на клиентской машине, а оно (хотя, сейчас такое редко встречается), вполне может отставать/опережать время сервера на какую-то дельту. Ну и это так же дополнительно породит для клиентов весьма специфичную ошибку "плохой ID сущности".
Смена хранилища (целиком, или для отдельной группы сущностей) - необходимость во всех внешних клиентах API менять механизм генерации ID этих сущностей.
Многие недооценивают важность гигиены. До 20-ти лет тоже не заморачивался, итог - одна шестёрка потеряна, вторая восстановлена из половинки, две остальные меньше пострадали, но тоже с пломбами.
"Ну, это наследственное", - сказали мне тогда.
И мне это не особо понравилось, т.к. такими темпами была перспектива к 30-ти годам вообще без зубов остаться. Стал после каждого приёма пищи тщательно полоскать рот. Даже после чашечки кофе, т.е. чтобы во рту вообще никогда не было лишней органики для размножения бактерий. Ну и утренняя + тщательная вечерняя чистка, разумеется. Вечерняя именно перед сном, а не как некоторые - зубы почистили, потом конфетой/печенькой закусили и спать. Итог - спустя 20 лет новых проблем не прибавилось, только пломбы за это время слегка поизносились и сейчас требуют реставрации/замены.
В общем случае - вручную. Т.е. в реализации get-метода репозитория необходимо забрать данные из какого-то хранилища (например, из БД) и затем на основании этих данных последовательно воссоздать агрегат через вызов соответствующих конструкторов/фабрик/методов. Аналогично - при сохранении.
В частных случаях это можно переложить на ORM, описав правила через fluent API. При этом ORM может либо уметь использовать конструкторы с параметрами, либо устанавливать значения свойств в обход бизнес-правил через рефлексию.
Только вручную. И только если в обновлении есть действительно острая необходимость. Т.к. любое обновление — это всегда риски как явных ошибок в самой версии, так и шанс отвала плагинов или потери привычного UI.
* Firefox 48-й версии.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Веб-версия AutoCAD.
Figma.
И не только сериализаторы. При проекции данных из БД в объекты при помощи Dapper можно получить схожий сценарий, если значения целочисленного поля в БД не соответствуют значениям в перечислении. В т.ч. можно получить enum-свойство, значение которого вовсе отсутствует в перечислении.
Если отдавать генерацию на сторону клиента, то это порождает сценарии, которые сложно контролировать.
Требуется как-то заставить всех внешних пользователей вашего API применять строго определённую схему генерации условно-последовательных GUID, которые будут наилучшим образом подходить для конкретного используемого хранилища. Например, у MSSQL свой подход к сортировке кластеризованных PK типа 'uniqueidentifier' (по части байтов). У другой БД может быть другой подход. А если разные сущности хранятся в хранилищах разного типа, то для каждой сущности придётся описывать свой тип генерации ID. А если использовать полностью случайные GUID, то это может порождать описанные в начале статьи проблемы с производительностью хранилища.
При этом сервер не имеет возможности как-то контролировать корректность генерации, т.е. мы вынуждены верить клиенту. А если такую возможность и реализовать (под конкретный тип хранилища), то она всё равно будет работать с определёнными допущениями, т.к. для генерации последовательного ID в любом случае придётся применять системное время на клиентской машине, а оно (хотя, сейчас такое редко встречается), вполне может отставать/опережать время сервера на какую-то дельту. Ну и это так же дополнительно породит для клиентов весьма специфичную ошибку "плохой ID сущности".
Смена хранилища (целиком, или для отдельной группы сущностей) - необходимость во всех внешних клиентах API менять механизм генерации ID этих сущностей.
Многие недооценивают важность гигиены. До 20-ти лет тоже не заморачивался, итог - одна шестёрка потеряна, вторая восстановлена из половинки, две остальные меньше пострадали, но тоже с пломбами.
"Ну, это наследственное", - сказали мне тогда.
И мне это не особо понравилось, т.к. такими темпами была перспектива к 30-ти годам вообще без зубов остаться. Стал после каждого приёма пищи тщательно полоскать рот. Даже после чашечки кофе, т.е. чтобы во рту вообще никогда не было лишней органики для размножения бактерий. Ну и утренняя + тщательная вечерняя чистка, разумеется. Вечерняя именно перед сном, а не как некоторые - зубы почистили, потом конфетой/печенькой закусили и спать. Итог - спустя 20 лет новых проблем не прибавилось, только пломбы за это время слегка поизносились и сейчас требуют реставрации/замены.
В общем случае - вручную. Т.е. в реализации get-метода репозитория необходимо забрать данные из какого-то хранилища (например, из БД) и затем на основании этих данных последовательно воссоздать агрегат через вызов соответствующих конструкторов/фабрик/методов. Аналогично - при сохранении.
В частных случаях это можно переложить на ORM, описав правила через fluent API. При этом ORM может либо уметь использовать конструкторы с параметрами, либо устанавливать значения свойств в обход бизнес-правил через рефлексию.
* Firefox 48-й версии.