Мне не нужен / не нужен ключ!

Question

У меня есть некоторые представления, которые я хочу использовать EF 4.1 для запроса.Это конкретные оптимизированные представления, в которых не будет ключей для обсуждения;не будет никаких удалений, обновлений, просто хороший выбор.

Но EF хочет, чтобы ключ был установлен на модели.Есть ли способ заставить EF двигаться дальше, не о чем беспокоиться?

Подробнее

Основная цель этого - запросить набор представленийкоторые были оптимизированы по размеру, параметрам запроса и соединениям.Базовые таблицы имеют свои PK, FK и так далее.Он проиндексирован, статистизирован (что за слово?) И оптимизирован.

Я бы хотел иметь класс, подобный (это гораздо меньшая и более простая версия того, что у меня есть ...):

public MyObject //this is a view
{
   Name{get;set}
   Age{get;set;}
   TotalPimples{get;set;}
}

и хранилище, построенное из EF 4.1 CF, где я могу просто

public List<MyObject> GetPimply(int numberOfPimples)
{
    return db.MyObjects.Where(d=> d.TotalPimples > numberOfPimples).ToList();
}

Я мог бы выставить ключ, но какова реальная цель отображения естественного ключа из 2 или 3 столбцов?Это никогда не будет использовано?

Текущее решение

Похоже, что их решение EF CF не будет, я добавил в модель сложный ключ и выставляю егов модели.В то время как это идет «в ногу» с тем, что можно ожидать от «хорошо спроектированной» модели БД, в данном случае, IMHO, она добавила только конструктор моделей, больше логики, больше байтов по проводам и дополнительные свойства накласс.Они никогда не будут использованы.

Answer 1

Нет пути. EF требует уникальной идентификации записи - ключа объекта. Это не значит, что вы должны выставить какой-либо дополнительный столбец. Вы можете пометить все ваши текущие свойства (или любое подмножество) как ключ - именно так EDMX делает это, когда вы добавляете представление базы данных в модель - он проходит по столбцам и помечает все необнуляемые и не вычисляемые столбцы как первичный ключ .

Вы должны знать об одной проблеме - EF внутренне использует карту идентификации , а ключ объекта является уникальным идентификатором в этой карте (каждый ключ объекта может быть связан только с одним экземпляром объекта). Это означает, что если вы не можете выбрать уникальную идентификацию записи и загружаете несколько записей с одной и той же идентификацией (вашим определенным ключом), все они будут представлены одним экземпляром сущности. Не уверен, что это может вызвать проблемы, если вы не планируете изменять эти записи.

Answer 2

Один из способов сделать это - вообще не использовать представления.

Просто добавьте таблицы в свою модель EF и позвольте EF создать SQL, который вы в данный момент пишете вручную.

Answer 3

EF ищет уникальный способ идентификации записей. Я не уверен, что вы можете заставить его идти вразрез с природой желания чего-то уникального в предметах.

Но это ответ на вопрос «покажи мне, как решить мою проблему так, как я хочу ее решить», а не на самом деле для удовлетворения основных потребностей бизнеса.

Если это «Я не хочу показывать пользователю ключ», то не связывайте его, когда привязываете данные к форме (веб или окна). Если это проблема «Мне нужно поделиться этими элементами, но я не хочу давать им ключи», то сопоставьте или замените объекты в модели внешнего домена. Добавляет немного веса к решению, но позволяет вам выполнять тяжелую работу с помощью поверхности перетаскивания (EF).

Вопрос в том, что является бизнес-требованием, которое подталкивает вас к созданию группы объектов без уникального идентификатора (ключа).