Как переопределить equals для определенного класса NHibernate - PullRequest
Новая
       18

Как переопределить equals для определенного класса NHibernate

0 голосов
/ 15 июля 2009

Я изо всех сил пытаюсь выяснить, как я должен переопределить equals и получить хэш-код для класса, который я пишу, используя NHibernate.

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

Итак, у меня есть «пользователь», у которого много «исторических паролей» ... класс пользователя был прост, поскольку я просто использовал логин в равных. Ниже мой класс HistoricalPassword. 

public class HistoricalPassword
{
    public virtual int HistoricalPasswordId { get; set; }
    public virtual User User { get; set; }
    public virtual DateTime ChangeDate { get; set; }
    public virtual string FormerPassword { get; set; }
}

Я бы сказал с деловой точки зрения, что комбинация User и ChangeDate даст мне равенство. Однако ... кажется неправильным ссылаться на пользователя в методе equals (поскольку, с одной стороны, это может привести к отложенной загрузке) ... а также из того, что я прочитал с использованием PK HistoricalPasswordId, нет-нет а также.

Кто-нибудь может дать какой-нибудь совет о том, как они переопределят равные для этого?

РЕДАКТИРОВАТЬ ::: Я думаю, что, возможно, немного вводил в заблуждение то, как я задал вопрос. Меня не смущает вопрос о том, как обеспечить соблюдение бизнес-правила, заключающегося в том, чтобы пароли не использовались повторно ... ни о том, как я знаю, равны ли два пароля или они безопасны. Что я действительно хочу знать, так это на уровне сущностей, конкретно относящихся к NHibernate, как бы я переопределил Equals для этого объекта, чтобы NHibenate не заканчивался дублированием в сеансе и / или кэше. Согласно документу NHibernate (https://www.hibernate.org/hib_docs/nhibernate/html/persistent-classes.html) я должен переопределить equals, используя равенство бизнес-ключей. В этом случае я просто не уверен, что использование ссылочного объекта User в сравнении является хорошей идеей.

Ответы [ 3 ]

2 голосов
/ 15 июля 2009

Я бы не переопределил Equals для этого - вы не утверждаете, что эти записи равны, просто они ссылаются на один и тот же пароль, не так ли?

Конечно, вам просто нужен запрос HQL или критерий, который дает вам исторические пароли, установленные за последние 90 дней?

РЕДАКТИРОВАТЬ: Также вы можете проверить, как вы храните свой пароль. Открытые пароли в базе данных не очень хорошая идея. Возможно, у вас есть пользовательский тип NHibernate, который расшифровывает зашифрованный пароль в строковое свойство, которое мы, конечно, видим ...

0 голосов
/ 15 июля 2009

Пару способов вы могли бы пойти по этому поводу.

Если вы хотите сделать это, используя равенство, тогда будет задействован пользователь, в частности, ПК пользователя. Равенством будет пользователь ПК + пароль. Дата не имеет значения. Это, вероятно, слишком усложняет ситуацию, и я бы, наверное, не пошел этим путем.

Другой способ - использовать только пароль для равенства, поскольку в конце вы сравниваете его. Пользователь будет использоваться только в запросе, то есть до даты изменения.

Выполните HQL-запрос, чтобы получить исторические пароли, где user = {user} и дата изменения

Наконец, как упоминалось выше, просто сделайте HQL-запрос для {user}, где дата изменилась <90 и password = {новый пароль}. Если вы получите какие-либо результаты назад, вы знаете, что пароль использовался в течение последних 90 дней. </p>

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

0 голосов
/ 15 июля 2009

Я бы посчитал HistoricalPassword объектом значения, а не сущностью.

Таким образом, это означает, что его 'ID' будет определяться значением всех его свойств.

...