Поддержка кастомных типов данных без доработок сервисов данных 🚀

[bratchikov]

Цель

Поддержка кастомных типов данных без доработок сервисов данных.

Функциональные требования

Требуется реализовать интерфейс, который позволит избавиться от необходимости уникальным образом обрабатывать кастомные типы данных на уровне самого сервиса данных. В качестве примера можно привести типы данных ГИСа, файловые типы. В данный момент без доработки DataService или без наследования невозможно ввести сложный тип. Надо преодолеть эту проблему. Обратная совместимость должна остаться.

Требования к реализации

В данный момент есть атрибут StoreInstancesInTypeAttribute, который задаёт соответствие кастомного типа типу данных в C#. Проблема в том, что этого недостаточно для формирования корректного SQL.
Реализация GisMSSQLDataService указывает на то, что нужно реализовать интерфейс, включающий в себя реализацию метода, аналогичного ConvertValueToQueryValueString и FunctionToSql.
Данный интерфейс должен использоваться ORM-ом для обработки кастомного типа, если тип поддерживает этот интерфейс.

Исходный код

Этот проект. Создать feature-ветку от develop.

Документация

Отразить изменения в документации по ORM.

Тесты

Добавить тест, который позволит проверять добавленную функциональность.

Аналоги, примеры реализации

• Реализация должна позволить избавиться от наследников сервиса данных для Gis-типов: https://github.com/Flexberry/NewPlatform.Flexberry.ORM.GisMSSQLDataService и https://github.com/Flexberry/NewPlatform.Flexberry.ORM.GisPostgresDataService/.

Примерная оценка трудоёмкости

24ч

[NicholasNoise]

Дополнительные ссылки:

• Information.GetStorageTypeForType
• SQLDataService.ConvertValueToQueryValueString
• SQLDataService.ConvertSimpleValueToQueryValueString
• InOperatorsConverter.Convert

[NicholasNoise]

Кажется, что стоит вынести всё тело метода SQLDataService.ConvertSimpleValueToQueryValueString в отдельный сервис. Где-то внутри него добавить приведение объекта к создаваемому интерфейсу и вызов метода конверсии в строку, реализующего метод интерфейса.

[StenvL]

Не стоит ли также в рамках данного issue реализовать добавление кастомной логики проверки на равенство двух объектов? Сейчас сравнение происходит здесь.

Если рассмотреть пример с тем же JObject ( #30 ), то равенство двух JObject проверяется при помощи метода JObject.DeepEquals, и сейчас нормального сравнения JObject можно достичь только модифицируя ORM, что несколько противоречит идее данного issue (в теории можно сравнить JObject-ы путём приведения их к строке в самом простом виде, но корректнее всё-таки через метод DeepQuals).

Как вариант реализации подобного - создать сервис для работы с реализацией данного интерфейса, получать его в сборке ICSSoft.STORMNET.DataObject и в классе Information (здесь) проверить, необходимо ли проводить сравнение по кастомной логике, либо же по стандартной.