Оптимизация функционирования ODataService отсечением лишних загрузок

[Anisimova2020]

Цель

Оптимизация функционирования ODataService путём отсечения излишних загрузок

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

Организовать работу ODataService так, чтобы при получении запроса не производились ненужные вычитки (особенно громоздких мастеров, которые при этом могут ещё и с детейлами прийти, хотя по сути не меняются).

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

Выявлены несколько аспектов, что позволит уменьшить нагрузку в ODataService излишними загрузками:

1. С фронтенда помимо изменённых атрибутов всегда приходят мастера, даже если они не менялись (данный аспект передан в проект ember-flexberry, чтобы разобраться в причинах такого поведения и его коррекции).
2. В случае прихода мастера на изменение (то есть поменялся сам первичный ключ, а не мастер) достаточно проверки на существование мастера.
3. Можно изменить представление по умолчанию, по которому идёт загрузка объекта (отдать на откуп прикладному программисту возможность переопределить представление по умолчанию).

<Подсказки программисту как решить поставленную задачу>
В общем случае, если вдруг мастер меняется, то при смене мастера у её объекта происходит загрузка тяжелющего мастера (а если ещё детейлы, то подгрузка детейлов). Хотя по логике у нас просто ссылка на мастера поменялась (и при этом адекватна проверка на существование такого мастера в принципе).

Вот здесь есть код, отмеченный, что для обратной совместимости, можно что-то подобное сделать:

Вот у нас батчем пришла пачка объектов.

1. в батче этого мастера отдельно нет, тогда сделать что-то типа lightloaded с проверкой на существование в БД. И в объекте только первичный ключ.
2. в батче этот мастер есть отдельно. Он либо берётся из кэша, если полноценно загружен. Если он пришёл в кэше lightloaded вариант, то тогда и догружается полноценно.

Особенностью данного решения является то, что в бизнес-сервере будет не вся та информация, которая раньше была там из-за работы ODataService, поэтому после реализации требуется менять мажорную версию.

По поводу смены дефолтного представления: можно подумать как сделать красиво, чтобы можно было переопределить этот метод, или действительно сделать глобальную настройку на уровне какой-нибудь инстанции ODataService при регистрации, чтобы зачитка была не такой жадной.

Исходный код

• применение дефолтного представления .
• [формирование дефолтного представления ].(

  NewPlatform.Flexberry.ORM.ODataService/NewPlatform.Flexberry.ORM.ODataService/Model/DynamicView.cs

  Line 407 in ee49b2b

  public static DynamicView Create(Type dataObjectType, List<string> properties, Dictionary<string, DynamicView> cache = null)

  ).
• [загрузка объекта по дефолтному представлению].(https://github.com/Flexberry/NewPlatform.Flexberry.ORM.ODataService/blob/ee49b2b879697358766a75cc90767e541d7a6329/NewPlatform.Flexberry.ORM.ODataService/Controllers/DataObjectController.ModifyData.cs#L706C27-L706C27).
• формирование объекта в целом (именно из этого метода отправляется в рекурсию для загрузки мастера, а потом его детейлов).

Тесты

Нужно сначала разработать тест, где меняется мастер у объекта и как-то зафиксировать, что попало в кэш.
Далее удостовериться, что в кэше после исправления мастер не полностью загружен.

[bratchikov]

Предлагаю в методе GetDataObjectByEdmEntity выполнить базовую оптимизацию:

• если некоторый метод вызывается в цикле, но может быть вызван единожды перед ним, то надо именно так и сделать
• во время итерирования не должен вызываться метод для получения коллекции каждый раз, а итерироваться надо по результату работы этого метода заранее сохранённому в переменную.