Nhibernate производства прокси, несмотря на HQL выборки

Question

У меня есть следующий HQL заявление:

select distinct t from TaskEntity as 
inner join fetch t.Case as c 
inner join fetch c.Client as client 
inner join fetch c.Matter as matter 

Однако, несмотря на Matter имея FETCH против него, он все еще возвращается в качестве прокси-сервера.

Мое отображение для этого объекта ниже

References(x => x.Matter).Columns(new[] {"c_client","c_matter" }); 

Я попытался с помощью JOIN на это, но мой вопрос, я собираюсь от 1 до 2 колонок, так что не будет принимать отображение.

Любые мысли?

Спасибо,

Answer 1

Я разработал проблему, которая вызывает эту проблему.

Он также разделяет на составные ID!

Ранее в проекте Nhibernate было предупреждение, что я не был переопределение Equals и GetHashCode, чтобы обойти много изменений кода, а также содействовать код повторного использования я сделал класс CompositeBaseEntity:

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 

namespace Case.Infrastructure 
{ 
    public class BaseCompositeEntity : BaseEntity 
    { 
     public override int GetHashCode() 
     { 
      return base.GetHashCode(); 
     } 

     public override bool Equals(object obj) 
     { 
      return base.Equals(obj); 
     } 
    } 
} 

Этот класс, возвращает на место то, что Нюбернэйт говорил мне избегать! Как есть два ключа для сравнения равенства против, мы должны переопределить Равно & GetHashCode() методы, чтобы стать чем-то вроде:

public override bool Equals(object obj) 
     { 
      if (obj == null) 
       return false; 
      var t = obj as ClientMatterEntity; 
      if (t == null) 
       return false; 
      if (AccountNumber== t.ClientAcconuntNumber && CaseNumber == t.CaseNumber) 
       return true; 
      return false; 
     } 

Таким образом, Nhibernate точно знает, как сравнение должно быть сделано, и тогда знает, что если он имеет этот объект в кеше первого уровня (который он будет, как мы указали, выборку).

Более подробную информацию можно найти здесь: http://nhforge.org/blogs/nhibernate/archive/2010/07/01/nhibernate-and-composite-keys.aspx

Answer 2

Имейте в виду, что вы также должны обеспечить правильную реализацию GetHashCode.

Ваша реализация Equals также невелика.

Кроме того, оба метода должны возвращать значения «статические». Я не видел свой класс, но это должно быть что-то вроде:

public class TaskEntity 
{ 
    public int AccountNumber { get; protected set; } 
    public int CaseNumber { get; protected set; } 
    public Client Client { get; set; } 
    public Matter Matter { get; set; } 

    public TaskEntity(int accountNr, caseNr) 
    { 
     AccountNumber = accountNr; 
     CaseNumber = caseNr; 
    } 

    protected TaskEntity() {} // Needed for NHibernate proxies 
} 

Я действительно рекомендую вам положить компонент идентификаторов в отдельно классах, когда это возможно.

Кроме того, прочитайте следующую статью о переопределении Equal, поскольку ваша текущая реализация, вероятно, имеет недостатки: http://msdn.microsoft.com/en-us/library/bsc2ak47.aspx особенно понимают часть относительно наследования и базовых типов.