EF entity + child entity
От: IQuerist Мухосранск  
Дата: 13.06.19 07:52
Оценка:
Добрый день

В очередной раз возникла ситуация. В проекте на EF есть DataProvider, с методами, которые по ряду условий возвращают массивы entity из БД. Для определенных ситуаций было бы здорово возвращать entity с заполненными child/parent entity, но совсем не хочется разводить бардак, когда у части объектов child/parent entity заполнены, а у части — нет, а отследить все можно только в runtime.

Вроде бы напрашивается решение для каждого варианта заполнения сделать отдельный тип. Но не совсем понятно как их например именовать.

Может кто знает красивое решение этой ситуации?
Re: EF entity + child entity
От: RushDevion Россия  
Дата: 13.06.19 09:13
Оценка:
Не знаю как насчет красиво, но имхо, если с точки зрения вызывающего кода отсутствие части child/parent сущностей — это нормальная ситуация,
то логично дать клиенту твоего DataProvider возможность самому указывать какие связи необходимо загружать.
А вот как это сделать зависит от внешнего интерфейса DataProvider.
Если наружу торчит IQueryable, то можно вообще не заморачиваться, пусть клиент пользуется стандартным Include.
Если же DataProvider абстрагирован от EF и наружу из него торчат коллекции/массивы, то можно попробовать Specification-паттерн (e.g. LinqSpecs)
Re[2]: EF entity + child entity
От: IQuerist Мухосранск  
Дата: 13.06.19 09:54
Оценка:
Здравствуйте, RushDevion, Вы писали:

RD>Не знаю как насчет красиво, но имхо, если с точки зрения вызывающего кода отсутствие части child/parent сущностей — это нормальная ситуация,

RD>то логично дать клиенту твоего DataProvider возможность самому указывать какие связи необходимо загружать.
RD>А вот как это сделать зависит от внешнего интерфейса DataProvider.
RD>Если наружу торчит IQueryable, то можно вообще не заморачиваться, пусть клиент пользуется стандартным Include.
RD>Если же DataProvider абстрагирован от EF и наружу из него торчат коллекции/массивы, то можно попробовать Specification-паттерн (e.g. LinqSpecs)

>>>логично дать клиенту твоего DataProvider возможность самому указывать какие связи необходимо загружать.


Вот для этого и планируется специализированные дочерние типы создавать. Типы фиксируют часть "протокола".

>>>Если наружу торчит IQueryable, то можно вообще не заморачиваться, пусть клиент пользуется стандартным Include.


Не мой случай.

>>>...то можно попробовать Specification-паттерн...


Пожалуй мои "клиенты" не так много знают о специфике источника и это не случайно. В любом случае вопрос об удобном именовании Specification-паттерн не решает.
Re[3]: EF entity + child entity
От: Danchik Украина  
Дата: 13.06.19 10:26
Оценка:
Здравствуйте, IQuerist, Вы писали:

IQ>Здравствуйте, RushDevion, Вы писали:


RD>>Не знаю как насчет красиво, но имхо, если с точки зрения вызывающего кода отсутствие части child/parent сущностей — это нормальная ситуация,

RD>>то логично дать клиенту твоего DataProvider возможность самому указывать какие связи необходимо загружать.
RD>>А вот как это сделать зависит от внешнего интерфейса DataProvider.
RD>>Если наружу торчит IQueryable, то можно вообще не заморачиваться, пусть клиент пользуется стандартным Include.
RD>>Если же DataProvider абстрагирован от EF и наружу из него торчат коллекции/массивы, то можно попробовать Specification-паттерн (e.g. LinqSpecs)

>>>>логично дать клиенту твоего DataProvider возможность самому указывать какие связи необходимо загружать.


IQ>Вот для этого и планируется специализированные дочерние типы создавать. Типы фиксируют часть "протокола".


Лучше создавай новые классы. Со временем увидишь что они к базе имеют отдаленное отношение. Как правило им дают суффикс DTO (Data Transfer Object) SomeDataDTO.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.