Как использовать свойства, доступные только для чтения, определенные в частичных (Entity Framework) классах через ADO.Net Data Services

Question

У меня есть объекты, которые определены Entity Framework, к которым я затем добавил дополнительные методы и свойства через частичные классы. Я думаю, что понимаю большинство ограничений, связанных с этим, но хотел подтвердить что-то, что вижу (или, надеюсь, узнать, что мне нужно сделать, чтобы сделать эту работу).

У меня есть частичный класс, который затем имеет свойство только для чтения, которое использует пару элементов для создания вычисляемого поля, доступного только для чтения. Было любопытно видеть, что свойство только для чтения не возвращалось через ADO.Net Data Services, как я надеялся / ожидал. то есть я ожидал увидеть свойства в платформе сущностей, а свойство, определяемое в коде через частичный класс, поступило через вызов службы данных.

Это так? Частичные классы полностью игнорируются, когда ADO.Net Data Services запрашивает данные? Если да, то каков наилучший способ получения свойства типа «только для чтения» для сущности (поскольку я хотел бы избежать вырезания и вставки одних и тех же частичных классов с разными пространствами имен как в клиентскую, так и в серверную базы кода). 1005 *

Answer 1

Из сообщения на форуме Microsoft: ( см. Полный пост здесь )

«Я думаю, что вы спрашиваете» Как добавить свойство только для чтения для существующего сущность, которая выставлена ​​EF провайдер "? В V1 нет хорошего способа сделать это. Для EF мы загружаем метаданные с помощью API метаданных EF и, следовательно, мы не делаем никакого отражения. Отсюда дополнительные свойства, которые вы мог бы добавить через частичный класс будет проигнорировано.

Астория еще не имеет понятия свойства только для чтения. Так что, если мы выставляем любые другие свойства, которые не являются частью модели, мы не знаем, как разобраться с ними в обновлениях. Мы не хочу потерять данные в сервер также. "

Похоже, что это функциональность, которую нельзя открыть через ADO.Net Data Services.

Answer 2

Здесь есть две отдельные проблемы - базовая модель (EF) и слой WCF / mex. Ваши дополнительные свойства не будут частью модели edmx, но мне интересно, не связана ли эта проблема больше с аспектом WCF / mex.

Однако, даже если это работает, ADO.NET Data Services передает данные , а не логика . Поэтому полагаться на рассчитанные свойства не является безопасным вариантом: у клиента не будет формул - только исходные значения.

Чтобы выяснить, что это, попробуйте сделать свойство доступным для чтения / записи (даже если запись не делает ничего полезного) и убедитесь, что значение имеет атрибут [DataMember] и т. Д.

Answer 3

Мне кажется, проблема в том, что при сериализации XML он только сериализует свойства с помощью методов get и set. Иначе это не могло бы десериализоваться. Добавьте пустой метод set к вашему свойству и посмотрите, как вы пойдете.

Rob