Не знаю как насчет красиво, но имхо, если с точки зрения вызывающего кода отсутствие части child/parent сущностей — это нормальная ситуация,
то логично дать клиенту твоего DataProvider возможность самому указывать какие связи необходимо загружать.
А вот как это сделать зависит от внешнего интерфейса DataProvider.
Если наружу торчит IQueryable, то можно вообще не заморачиваться, пусть клиент пользуется стандартным Include.
Если же DataProvider абстрагирован от EF и наружу из него торчат коллекции/массивы, то можно попробовать Specification-паттерн (e.g.
LinqSpecs)
Здравствуйте, RushDevion, Вы писали:
RD>Не знаю как насчет красиво, но имхо, если с точки зрения вызывающего кода отсутствие части child/parent сущностей — это нормальная ситуация,
RD>то логично дать клиенту твоего DataProvider возможность самому указывать какие связи необходимо загружать.
RD>А вот как это сделать зависит от внешнего интерфейса DataProvider.
RD>Если наружу торчит IQueryable, то можно вообще не заморачиваться, пусть клиент пользуется стандартным Include.
RD>Если же DataProvider абстрагирован от EF и наружу из него торчат коллекции/массивы, то можно попробовать Specification-паттерн (e.g. LinqSpecs)
>>>логично дать клиенту твоего DataProvider возможность самому указывать какие связи необходимо загружать.
Вот для этого и планируется специализированные дочерние типы создавать. Типы фиксируют часть "протокола".
>>>Если наружу торчит IQueryable, то можно вообще не заморачиваться, пусть клиент пользуется стандартным Include.
Не мой случай.
>>>...то можно попробовать Specification-паттерн...
Пожалуй мои "клиенты" не так много знают о специфике источника и это не случайно. В любом случае вопрос об удобном именовании Specification-паттерн не решает.
Здравствуйте, 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.