#entity-framework #entity-framework-4
#entity-framework #entity-framework-4
Вопрос:
Говоря «Производные объекты», я имею в виду те «объекты домена», которые не могут быть напрямую сопоставлены с таблицами БД, но все еще существуют «между строками» и могут быть восстановлены с использованием правил агрегирования / ранжирования.
Пример: У меня есть таблица, в которой записи имеют два DateTimes для управления периодами времени. Используя сложное, но все же естественное правило, основанное на интерпретации объединения этих периодов и некоторых других полей, мы группируем эти записи в эпизоды. Эти «Эпизоды» или «агрегированные записи» являются довольно популярными объектами в моей области, поэтому я ищу способ гибкой организации кода.
Что может предложить мне Entity Framework? Могу ли я каким-то образом объявить эти «эпизоды» в концептуальной модели? Или с точки зрения инструмента ORM эти «объекты домена» всегда являются «еще одним запросом»?
Теперь я создаю эти Eisode, используя «специальные» типы с выражением linq и циклом «foreach» (для получения агрегированных значений). Я называю этот код «бизнес-правилом», но без скрытого «объявления» на концептуальном уровне это «бизнес-правило» — просто «код» 🙂
PS Было бы лучше иметь эти эпизоды в БД, но сейчас это невозможно… PPS Entity Framework 4.1
Ответ №1:
Один из способов подумать об этом заключается в том, что у вас есть несохраняемый объект домена под названием Episode, который объединяет сохраняемые сущности. Сущности, являющиеся частью вашей модели (те, которые сохраняются), являются «членами» эпизода, основанного на логике, относящейся к полям временных меток.
Одним из подходов было бы определение класса Episode, который объединяет эти объекты модели. Классу Episode необязательно знать о постоянстве объектов модели — фактически, шаблон POCO также удаляет информацию о постоянстве из сохраняемых объектов модели.
Стратегия «присвоения» объекта модели эпизоду будет зависеть от используемой логики. Вы могли бы добавить статический метод к классу Episode, который принимает объект модели в качестве параметра. Затем этот метод мог бы применять логику назначения, создавая экземпляры новых эпизодов и присваивая им объекты модели соответствующим образом.
Комментарии:
1. Я понимаю это так: «вы не обязаны думать только о сохраняемых сущностях, вы вольны инкапсулировать свою логику в новые классы; классы уровня персистентности — это просто классы уровня персистентности»