Какой из них лучше в качестве свойства модели POCO: ForeignKey / ID или Ссылка на объект? - PullRequest
0 голосов
/ 23 ноября 2011

Привет, я начинаю использовать EF 4.1 и POCO в проекте, над которым я работаю. Модель, которую я использую, выглядит следующим образом:

 public class Contact1
    {
        // Primary key
        public int ID { get; set; }

        public string FirstName { get; set; }
        public string LastName { get; set; }
        public virtual Address DelAddress { get; set; }
        public virtual Address POAddress { get; set; }
        public string EmailAddress { get; set; }
        public bool InActive { get; set; }
        public string Comment { get; set; }
        public string Phone1 { get; set; }
        public string Phone2 { get; set; }
    }

Но я видел довольно много примеров использования ForeignID в качестве ссылки для поля, такого как Address, и я использую прямую ссылку на объект Address в моей модели. Я думаю, что использование ссылок лучше, потому что я имею дело с Объектами на этом уровне, но не с записями или уровнем БД, на которые в любом случае будет ссылаться идентификатор. Но все же, что бы вы использовали для своей модели Code First?

1 Ответ

0 голосов
/ 28 ноября 2011

При условии, что все остальные вещи равны, ссылки на объекты лучше, потому что "шум" "мягких" ссылок на основе идентификаторов загрязняет вашу модель.

Тем не менее, все остальные вещи не равны, как пишет Ладиславв Внешний ключ против независимых ассоциаций в EF 4 .Например, независимые ассоциации требуют, чтобы у вас были оба конца отношений в памяти.Это может быть немного проблематично при сохранении обновлений в том смысле, что вам нужно загрузить цель отношения, если в противном случае вы не загрузили бы ее в ObjectStateManager.Это особая проблема при сохранении сущности, имеющей много ссылок на сущности типа «опорные данные», и при работе в N-уровневой архитектуре.

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

...