Среди множества проблем с STE я сейчас сталкиваюсь с этой, которая должна быть тривиальной, но не такой:
Для простоты, давайте предположим стандартный счет, заказ, сценарий продукта.
Допустим, у меня есть уровень без сохранения состояния (по какой-либо причине), который получает счет-фактуру и добавляет некоторые заказы для некоторых продуктов перед отправкой счета обратно на уровень, с которого он получен.
Звучит просто, нона самом деле проблема с STE, для которой я не нашел простого решения.Проблема заключается в том, как сохранить коллекцию сущностей продукта для присвоения заказам.На мой взгляд, мне придется сделать это одним из следующих способов, чтобы у всех были основные недостатки:
Запрос к базе данных для объекта продукта для каждого заказа, который я хочу разместить в объекте-счете-фактуре..
Недостатки: если один и тот же продукт используется в нескольких заказах, EF сгенерирует исключение, когда изменения счета будут сохранены в базе данных, поскольку несколько экземпляров одного и того же ключа продукта не допускаются вконтекст.Я мог бы убедиться, что продукты, встречающиеся в нескольких заказах, запрашиваются только один раз, а затем распределяются между заказами, но это определенно усложнит ситуацию.
Другим недостатком является производительность, если объекты продукта (или эквивалентные объекты в другом доменном сценарии) достаточно велики или запрос базы данных для продуктов на уровне приложения нецелесообразен по любой причине.
Запрос к базе данных для всех сущностей продуктов в начале срока действия приложения
Это будет типичный сценарий, если вы сохраняете список продуктов в пользовательском приложении, если список продуктов редко изменяется.В моем случае я не хочу запрашивать базу данных, так как список типов «product» никогда не изменяется в течение времени жизни приложения, производительность является важной проблемой, и система должна быть устойчивой, чтобы база данных была временно недоступна, поэтому я хочусохранить кэшированную коллекцию эквивалентных сущностей «product».
Недостатки: главный недостаток в том, что назначение кэшированных продуктов новым сущностям заказа приведет к утечке памяти.Причина этого заключается в том, что методы «Fixup», сгенерированные STE, будут подключать обработчик событий к ChangeTracker продукта для обработки каскадного удаления продукта.Этот обработчик событий сохранит новый заказ и подключенный кешированный продукт, накапливая все заказы, добавленные за время существования кэша.Решением может быть реализация какого-либо свойства «замораживания» STE, так что не только будет отключено отслеживание изменений, но состояние объекта и средства отслеживания изменений останутся неизменными даже после присвоений свойств навигации.Подобную «замораживающую» модификацию может быть сложно написать, поскольку код STE имеет множество побочных эффектов, затрудняющих их модификацию.
Создание клонов сущностей продукта
Здесь продукты запрашиваются в начале жизненного цикла приложения, но вместо использования сущностей продуктов создаются клоны при назначении продуктов заказам.Это решило бы проблему утечки памяти, но клонирование должно было бы быть осуществлено и поддержано.Возможно, что было бы не слишком сложно переписать сценарии STE .tt для поддержки клонирования.Тем не менее, все еще будет проблема с несколькими объектами в контексте объекта, использующими один и тот же ключ.