Отображения NHibernate, когда отношения самосоединения имеют дополнительные свойства
Отвечая на мой вопрос здесь, на случай, если кто-то столкнется с той же проблемой.
Вам нужно использовать группы репликации, а не кластеры кэша, если вам нужен экземпляр ElastiCache Redis с включенным AUTH. Не забудьте также включить шифрование в пути, поскольку они оба идут рука об руку.
2 ответа
Я думаю, что сделал бы это как этот также, но, я думаю, что это немного 'неуклюже' для моделирования его как это. Я имею в виду: у Вас есть набор людей, с которыми связан конкретный человек, но у Вас также есть 'заднее отношение'.
Это действительно необходимо? Разве это не опция удалить этот задний набор и вместо этого, указать метод на PersonRepository, который может дать Вам всем людей назад, которые имеют некоторое отношение с данным человеком?
Хм, это может, возможно, звучать немного неясным, так здесь некоторый код (обратите внимание, что ради краткости, я не учел 'виртуальные' модификаторы и т.д. (Я также предпочитаю не иметь те модификаторы, таким образом, в 99% времени, я указываю 'lazy=false' при своем отображении класса).
public class Person
{
public int Id {get; set;}
public string Name {get; set;}
public IList<PersonPerson> _relatedPersons;
public ReadOnlyCollection<PersonPerson> RelatedPersons
{
get
{
// The RelatedPersons property is mapped with NHibernate, but
// using its backed field _relatedPersons (can be done using the
// access attrib in the HBM.
// I prefer to expose the collection itself as a readonlycollection
// to the client, so that RelatedPersons have to be added through
// the AddRelatedPerson method (and removed via a RemoveRelatedPerson method).
return new List<PersonPerson) (_relatedPersons).AsReadOnly();
}
}
public void AddRelatedPerson( Person p, RelationType relatesAs )
{
...
}
}
Как Вы видите, класс Человека только имеет в запасе один набор, который является набором объектов PersonPerson, который представляет отношения, которые имеет этот Человек. Для получения Людей, которые имеют отношения с данным Человеком, Вы могли создать определенный метод на своем PersonRepository, который возвращает тех Людей, вместо того, чтобы иметь их в наборе на классе Человека. Я думаю, что это улучшит производительность также.
public class NHPersonRepository : IPersonRepository
{
...
public IList<Person> FindPersonsThatHaveARelationShipWithPerson( Person p )
{
ICriteria crit = _session.CreateCriteria <Person>();
crit.AddAlias ("RelatedPersons", "r");
crit.Add (Expression.Eq ("r.RelatedWithPerson", p));
return crit.List();
}
}
'Обратная ссылка' не является членом класса Человека; к этому нужно получить доступ через репозиторий. Это также, что Eric Evans говорит в своем DDD - книга: в некоторых случаях лучше иметь специальный метод для репозитория, который может предоставить Вам доступ к связанным объектам, вместо того, чтобы иметь их (= связанные объекты) для переноса вокруг с самим объектом.
Я не протестировал код, я просто ввел его здесь, таким образом, я также не проверял на синтаксическую ошибку, и т.д...., но я думаю, что он должен разъясниться немного о том, как я видел бы это.
Это смотрит на меня как, Вы по существу создали модель ориентированного графа и эти два отображения PersonPersonForward и PersonPersonBack представьте исходящие и входящие края соответственно.
Этот directedness укреплен семантикой Ваших Типов связей: в то время как is-a-Colleague-of наиболее вероятен, симметричное отношение, is-a-Manager-of и is-a-Tutor-of почти определенно асимметрично.
Я думаю в этом случае, что модель данных пытается сказать Вам, что два набора ссылок, в то время как из совместимого типа, не являются тем же самым в контексте.