Добрый день,
Есть такая замечательная книжка, NHibernate CookBook, вроде как уже адаптированная под NH 3.0, у нас в проекте правда 2.0, но вряд ли это что-то изменит.
Там был классный, замечательно продуманный пример для предка всех Entity, его я и заюзал недавно, а теперь вижу, что в переделанных под него сущностях возникли недетские, странные, неразрешимые проблемы :(
Главным образом пришлось заюзать его из-за следующей цепочки: есть связи М:М -> не нужны лишние insert и delete при каждом обновлении коллекции -> пришлось использовать <set> и ISet (Iesi) -> нужно перегрузить для таких коллекций Equals -> кто ж как не авторы NHibernate знают, как это правильней сделать? -> использовать пример из их книжки NHibernate 3.0 CookBook (по крайней мере лидер команды NH и еще один член участвовали в разработке книги).
Вот оно:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
using System;
namespace blablabla
{
public abstract class Entity<TId>
{
public virtual TId Id { get; /*protected*/ set; }
public override bool Equals(object obj)
{
return Equals(obj as Entity<TId>);
}
private static bool IsTransient(Entity<TId> obj)
{
return obj != null &&
Equals(obj.Id, default(TId));
}
private Type GetUnproxiedType()
{
return GetType();
}
public virtual bool Equals(Entity<TId> other)
{
if (other == null)
return false;
if (ReferenceEquals(this, other))
return true;
if (!IsTransient(this) &&
!IsTransient(other) &&
Equals(Id, other.Id))
{
var otherType = other.GetUnproxiedType();
var thisType = GetUnproxiedType();
return thisType.IsAssignableFrom(otherType) ||
otherType.IsAssignableFrom(thisType);
}
return false;
}
public override int GetHashCode()
{
if (Equals(Id, default(TId)))
return base.GetHashCode();
return Id.GetHashCode();
}
/// <summary>
/// Данный метод не из книжки, его добавил я.
/// Проверка двух entity на равенство. Используется при перегрузке оператора ==
/// Если одна из них Null, а другая нет, то они не равны. Два null равны.
/// </summary>
/// <typeparam name="TEntity">Тип entity</typeparam>
protected static bool AreEqual<TEntity>(TEntity entity1, TEntity entity2)
{
if ((object)entity1 == null)
{
return ((object)entity2 == null);
}
else
{
return entity1.Equals(entity2);
}
}
/// <summary>
/// Данный метод не из книжки, его добавил я.
/// Проверка двух entity на неравенство. Используется при перегрузке оператора !=
/// </summary>
/// <typeparam name="TEntity">Тип entity</typeparam>
protected static bool AreNotEqual<TEntity>(TEntity entity1, TEntity entity2)
{
return !AreEqual(entity1, entity2);
}
}
}
Типичный пример использования:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
using System;
using System.Collections.Generic;
using Iesi.Collections.Generic;
using ERP.Infrastructure.Entities;
namespace ERP.Wholesale.Domain.Entities
{
public abstract class Organization : Entity<int>
{
#region Методы
#region Перегрузка равенства, Equals и GetHashCode
public override bool Equals(object obj)
{
return base.Equals(obj);
}
public override int GetHashCode()
{
return base.GetHashCode();
}
public static bool operator ==(Organization object1, Organization object2)
{
return AreEqual(object1, object2);
}
public static bool operator !=(Organization object1, Organization object2)
{
return AreNotEqual(object1, object2);
}
#endregion
#endregion
}
}
Беда в том, что иногда метод GetUnproxiedType() выдает все же тип прокси!
Из-за этого метод Equals() выдал для двух entities с одинаковым id (когда после коммита unitofwork NH пытался писать в entity - в одно из полей то же самое значение, что и было), что они не равны.
Полная печаль :(
Как делают это профессионалы?
Думал я, что тот пример Entity<> не умеет работать с наследованием, но он в той части книги, где как раз наследование есть.
Реально у нас от Organization произошла COrganization, а от той - DOrganization. Вот создавалась связь этой DOrganization
Мы можем сделать виртуальный метод Get...Type в базовой Entity, а потом его перегружать, но стоит ли?
Реально у нас был сеттер одного из полей для защиты (раз уж сделали метод, меняющий поле, public в предыдущем примере от случайного изменения этого поля извне (по логике работы оно инициализировалось один раз при создании объекта и более не трогалось):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
public class Contract: Entity <short>
{
public virtual COrganization COrganization
{
get { return cOrganization; }
protected internal set
{
if (cOrganization != null && value != cOrganization) // != вызывает ==, которое вызывает Equals, который выз.GetUnproxiedType()
throw new Exception("Невозможно сменить организацию.");
}
cOrganization = value;
}
}
private COrganization cOrganization;
}
Вот конструировали новый Contract, который при конструировании ставил свое поле COrganization указывать на некую организацию. (И добавлял себя в коллекцию этой организации). Потом делали UnitOfWork.Commit, NH лезло в поле, писало в это поле организацию с тем же id, глючил GetUnproxiedType, потом неправильно они считались не равными, и сеттер ругался...
Можно, конечно, не пользовать операцию != для сущности, раз она глючит, и обойтись лямбдой: (... && value != null && value.Id != cOrganization.Id). Но как-то все равно нехорошо :( Например, теоретически в коллекцию может добавиться двойной элемент (с одним Id, а NH подумает, что он не равен сам себе, как сейчас). Ошибка будет где-то на уровне SQL, я думаю. Мы конечно будем руками через лямбды каждый раз проверять, есть ли элемент с таким Id в коллекции, но все равно как-то грустно. Сейчас надо весь проект переделать под новое Entity<>, а переделывать его на неработающий код как-то не лежит душа :(
