Требуется совет для Entity Framework Class / схемы базы данных - PullRequest
Новая
       4

Требуется совет для Entity Framework Class / схемы базы данных

1 голос
/ 05 октября 2011

Я недавно задал вопрос , и, откровенно говоря, исходя из полученного ответа, я второй раз угадываю всю свою стратегию / как я проектирую классы и базу данных.

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

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

   public class Person
    {
        public int ID { get; set; }
        public string name { get; set; }
        public Picture logo { get; set; }
    }

    public class Note
    {
        public int ID { get; set; }
        public string Text { get; set; }
        public Person Owner { get; set; }
    }

 public class Picture
    {
        public int ID { get; set; }
        public string Path { get; set; }
        public Person Owner { get; set; }
    }

Когда я хочу выбрать список заметок, которыми владеет человек, япросто выполните db.Notes.Where(x=>x.owner=="y") на объекте заметок.Я думаю, что понимаю, что если бы я использовал Icollection в классе person, я мог бы вместо этого выполнить что-то вроде db.person.select(x=> x.notes), чтобы получить все заметки.Правильно ли я верю в это мышление?

Если бы вы были на моем месте с относительно простым примером выше, как бы вы создавали классы (включая ICollection, виртуальные или что-то еще)?

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

Во многих примерах я имеючитал, (в приведенном выше примере) они будут использовать public int OwnerID вместо public person Owner.Это действительно бросило меня, и я подвергаю сомнению всю мою стратегию EF.В чем различия?

Буду признателен за любой совет.

1 Ответ

0 голосов
/ 22 октября 2011

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

public class Person 
{ 
    public int ID { get; set; } 
    public string name { get; set; } 
    public ICollection<Note> Notes { get; set; }
    public ICollection<Picture> Pictures { get; set; }
    public Picture logo { get; set; } 
} 

public class Note 
{ 
    public int ID { get; set; } 
    public string Text { get; set; } 
    public Person Owner { get; set; } 
} 

public class Picture 
{ 
    public int ID { get; set; } 
    public string Path { get; set; } 
    public Person Owner { get; set; } 
}

Итак, теперь скажем, что вы получили объект person, используя запрос 

var person = _context.People.Where(m=>m.ID=randomIntWeWant).First();

Мы можем получить все связанные предметы в качестве свойств.

Для заметок 

person.Notes

для фотографий 

person.Photos

ICollection связана с отложенной загрузкой. Объявляя свойство как ICollection с одной стороны, вы говорите, что между объектами существует отношение многие-к-одному. Если вы объявляете свойство как ICollection с обеих сторон, вы говорите, что это отношение «многие ко многим». EF заботится о создании таблиц, которые отслеживают эти отношения.

...