Выберите один-к-одному и компонент в NHibernate - PullRequest
Новая
       1

Выберите один-к-одному и компонент в NHibernate

2 голосов
/ 02 декабря 2010

Я пытаюсь отобразить классы User и Profile, как показано ниже: 

public class User
{
    public long ID { get; set; }
    public string LoginName { get; set; }
    public Profile Profile { get; set; }
}

public class Profile
{
    //the ID is the same with User's ID 
    public long ID { get; protected set; }
    public string NickName { get; set; }
    public Gender Gender { get; set; }
}

Таким образом, они могут быть отображены как отношения один-к-одному и как компоненты. И я нахожу, что некоторые люди оценивают компонент и думают, что один на один - плохая практика, почему? По причине производительности? Но они разработаны как две отдельные таблицы во многих сценариях (например, членство asp.net2.0).

Как мне выбрать? Какие аспекты я должен рассмотреть? Я знаю, что компонент означает «объект стоимости», но не единицу, но означает ли это что-то еще?

ps: И что меня больше смутило, так это мнение, что многие-к-одному должны использоваться, даже если это отношения один к одному в реальном мире!

Ответы [ 2 ]

3 голосов
/ 02 декабря 2010

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

Вам необходимо ответить на следующие вопросы:

  1. Имеет ли Профиль смысл как самостоятельная сущность?
  2. У вас есть ссылки на профиль где-либо еще в вашем домене?
  3. Можете ли вы иметь пользователя без профиля?
  4. Есть ли у него собственное поведение?
  5. Вы бы расширили (унаследовали) профиль по какой-то причине?
  6. В большинстве случаев используется только пользователь (и его LoginName, а не только идентификатор), а не профиль?

Если большинство вопросов верны, у вас есть хороший аргумент в пользу индивидуального общения (я не согласен с @Falcon; на самом деле это одно из законных вариантов использования индивидуального общения)

В противном случае компонент будет работать нормально. У него нет идентификатора, поэтому вы можете удалить это свойство.

2 голосов
/ 02 декабря 2010

Вы не должны использовать ни один из них.

One-To-One

У вас есть пользователь и профиль в разных таблицах базы данных, но оба совместно используют PK: См. http://jagregory.com/writings/i-think-you-mean-a-many-to-one-sir/

Довольно плохая практика проектирования для реляционных баз данных, это грязно и не обязательно навязывает ограничения для отношений.

Компонент

Вы можете использовать компонент для получения чистой объектной модели изГрязная реляционная база данных, профиль и пользовательские данные хранятся в одной и той же таблице базы данных, но они должны быть разделены в вашей объектной модели (как вы хотите, судя по вашему коду).Ленивая загрузка, вероятно, не поддерживается, что приведет к большому трафику базы данных.

Reference

Имхо, вам следует использовать Reference.Это концептуально, как один на один, но пользователь ссылается на профиль.Профили могут храниться в отдельной таблице, загружаться лениво (производительность) и не зависеть от пользователя.

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

...