Entity Framework "Кодовые запахи" Вопрос

Question

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

myEntity.MyLookup = db.MyLookups.First (ml => ml.MyLookupId == 5);

Я имею в виду, он не только выглядит странно, но и снова запрашивает базу данных, чтобы я мог эффективно присвоить значение «5». Я знаю, что это также возможно, если установить EntityKey через MyLookupReference, но это кажется еще более неприятным.

У меня вопрос: возможно ли избавиться от представления ассоциированного объекта в Store и просто рассматривать все как скаляр на моих сущностях, не имея свойств навигации и позволяя мне просто выполнять объединения при необходимости?

Кроме того, если это выполнимо, имеет ли это какое-либо влияние на то, кто отслеживается, или что-то в этом роде? Спасибо!

Answer 1

Я думаю, что это еще одна причина для отделения бизнес-логики от слоев доступа к данным. Вы можете уже сделать это, конечно.

Например, если у вас есть таблица User и таблица UserTypes. Ваш уровень данных должен иметь дело с этим, но бизнес-уровень не должен знать об этом, предполагая, что у вас есть некоторый фабричный метод в вашем адаптере данных, который принимает пользователя и тип пользователя и преобразует их в Администратора пример).

Не уверен, что это поможет, просто подумал, что я выскажу свое мнение.

Answer 2

Значения внешнего ключа - это боль в EF v1. То, как вы делаете это выше, является единственным способом, если вы не готовы создать EntityKey самостоятельно.

EF v4.0 устранит эту головную боль с помощью «FK Associations». Ассоциации FK - это обновляемые скалярные значения, которые представляют отношения.