Свободный вопрос архитектуры NHibernate

Question

У меня есть вопрос, который я могу переосмыслить на данный момент, но здесь идет ...

У меня есть 2 класса пользователей и групп. Пользователи и группы имеют отношение «многие ко многим», и я подумал, что в объединяющей таблице group_users я хотел иметь свойство IsAuthorized (поскольку некоторые группы являются частными - пользователям потребуется авторизация).

Вы бы порекомендовали создать класс для таблицы соединений, а также для таблицы пользователей и групп? В настоящее время мои классы выглядят следующим образом.

public class Groups
{
    public Groups()
    {
        members = new List<Person>();
    }
    ...
    public virtual IList<Person> members { get; set; }
}

public class User
{


    public User()
    {
       groups = new Groups()
    }
    ...
    public virtual IList<Groups> groups{ get; set; }

}

Мое сопоставление похоже на следующее в обоих классах (я показываю только одно в сопоставлении пользователей, но они очень похожи):

HasManyToMany<Groups>(x => x.Groups)
.WithTableName("GroupMembers")
.WithParentKeyColumn("UserID")
.WithChildKeyColumn("GroupID")
.Cascade.SaveUpdate();

Должен ли я написать класс для таблицы соединений, который выглядит следующим образом?

public class GroupMembers
{
    public virtual string GroupID { get; set; }
    public virtual string PersonID { get; set; }
    public virtual bool WaitingForAccept { get; set; }
}

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

Answer 1

Обычно я люблю создавать классы, которые представляют реальные бизнес-объекты. В этом случае я не думаю, что groupmembers представляет что-то ценное в вашем коде. Для меня ORM должен сопоставить базу данных с вашими бизнес-объектами. Это означает, что ваши классы не должны точно отражать структуру базы данных.

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

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

Затем они будут извлекать свои значения из таблицы соединений в базе данных на основе флага waittoaccept.

Answer 2

Да, конечно, вам нужен другой класс, такой как UserGroupBridge. Другим хорошим побочным эффектом является то, что вы можете изменять членство пользователей и членов группы без загрузки потенциально тяжелых объектов пользователя / группы в сеанс NHibernate.

Приветствие.