Entity Framework с POCO Serializable Classes and Lazy Загрузка

Я создал свои классы POCO с ICollection для связанных объектов. Они находятся в службе WCF, поэтому я их украсил DataContract/DataMember. Я не использую виртуальные свойства для связанных объектов, потому что они создают прокси-сервер, который не будет сериализоваться (я получаю, казалось бы, несвязанное сообщение «Основное соединение было закрыто», но когда я удаляю виртуальный модификатор, это исчезает.)Entity Framework с POCO Serializable Classes and Lazy Загрузка

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

Например, у меня есть класс Company, в котором есть свойство ICollection<Principals>. Обычно я не хочу загружать всех Принципов при получении Компании, но мне хотелось бы получить ссылку на Company.Principals, чтобы получить их. Ясно, что Company просто не может этого сделать сам по себе.

Что делают люди, чтобы объединить желания, чтобы иметь (1) объекты POCO, (2) типичную сериализацию WCF и (3) свойства, связанные с ленивой загрузкой?

источник

2012-06-13 Kelly Cline

Вот статья от MS, которая может помочь: http://msdn.microsoft.com/en-us/library/dd456855.aspx –

Вы хотите, чтобы ваши 'Company.Principals' заполнялись по запросу на сервере или на клиентском коде ? –

@GrzegorzWilczura, это как раз два соответствующих вопроса. По-видимому, Company.Principals должен иметь доступ к Контексту, следовательно, опция виртуальных свойств; Я начинаю понимать, что просто нецелесообразно заполнять клиентов по требованию клиентов. Однако в реальном мире все знают, что у Компании есть Принципы, поэтому кажется (по крайней мере, для клиента), что я остался с загрузкой всего графа объектов, независимо от того, насколько он большой. Это то, что все делают? Действительно ли POCO бесполезен, тогда (в отключенном случае, как и WCF), за исключением простейших примеров? –

Для ленивой загрузки требуют использовать прокси и свойства виртуальной навигации. Если у вас нет прокси, вы должны обрабатывать загрузку по-разному. Например, используя жадной загрузки:

var companies = context.Companies.Include("Principals").ToList();

или с EF 4.1

var companies = context.Companies.Include(c => c.Prinicpals).ToList();

Вы знаете, какую операцию следует загрузить связанные принципалов, а поэтому с помощью жадной загрузки не является проблемой. Использование ленивой загрузки в сервисе WCF с сериализацией всегда приведет к загрузке всего графа объектов.

источник

2012-06-14 08:24:25

Итак, мы должны быть осторожны, чтобы не отправлять всю базу данных по проводам, но для того, чтобы удовлетворить потребность клиента. I.e, нецелесообразно (за исключением простейших объектных графов) отправлять фактические основные объекты как Company.Principals? Другими словами, мы можем сделать так, чтобы, если Клиент ссылается на Company.Principals [0] .Name, он получает Name, но мы не осмеливаемся предоставить весь объект Principal, с помощью которого он мог ссылаться на Company.Principals [0] .References [0] .Чтобы [0] ... Является ли типичным то, что, если Клиент получает Принципов, у него есть другой тип, кроме Company.Principals [0]? –

Entity Framework с POCO Serializable Classes and Lazy Загрузка

ответ

Смежные вопросы