Прокси NHibernate вызывает проблемы с привязкой данных - PullRequest
3 голосов
/ 28 мая 2009

У меня есть сетка, связанная с результатом запроса nhibernate. Если первый элемент в списке редактируется, выдается следующее исключение:

System.Reflection.TargetException: Object does not match target type

Похоже, что проблема вызвана тем фактом, что привязка данных не может иметь дело с первым элементом в списке, являющимся подтипом других элементов в списке.

Какой хороший / правильный способ решить эту проблему? В настоящее время мне пришлось отключить прокси nhibernates.

Редактировать: У меня есть еще пара решений:

Но никто из них не чувствует себя хорошо, хотя ...

Ответы [ 5 ]

3 голосов
/ 08 июля 2009

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

Он также называется «SafeBindingList», как и другие предложения выше, но он не «клонирует» объекты для решения проблемы. Он просматривает объекты в списке, а затем, если никто не проксируется, список возвращается без изменений. Если один или несколько объектов проксированы, он добавляет пустой прокси к непроксируемым объектам, тем самым делая их все одного типа.

Итак, вместо того, чтобы возвращать List [T] для привязки, используйте SafeBindingList [T], чтобы все объекты имели одинаковый тип.

Это обновление для версии Castle, используемой с NH2.0.1: http://code.google.com/p/systembusinessobjects/source/browse/trunk/System.BusinessObjects.Framework/Data/SafeBindingLists.cs

Кроме того, кредит идет на оригинальный код и плакат: https://forum.hibernate.org/viewtopic.php?t=959464&start=0&postdays=0&postorder=asc&highlight=

2 голосов
/ 28 мая 2009

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

Я не думаю, что есть решение, кроме как не использовать привязку данных для заполнения сетки. Это достаточно просто, если оно доступно только для чтения.

0 голосов
/ 04 октября 2011

Очень поздно, но должно помочь другим с такой же проблемой. Решение, которое я использовал, заключается в том, чтобы обернуть пользовательский список (в данном случае NotificationList) вокруг поля в получателе.

private IList<IParameter> _parameters = new List<IParameter>();  
get  
{  
    return new NotificationList<IParameter>(_parameters);  
}

Этот список является оберткой вокруг списка, поэтому привязка данных будет перенаправлена ​​в исходный список.

public class NotificationList<T> : IList, IList<T>    
{
    IList<T> myList;
    public NotificationList(IList<T> list)
    {
        myList = list;
    }
    int IList.Add(object item)
    {
        myList.Add ((T) item);
    } 
    // implement both IList<T> and IList
    // ...
}

Для меня это исправило проблему с привязкой данных, но создало побочный эффект, при котором каждый раз при сбросе сеанса все элементы в коллекции обновлялись в БД, независимо от того, изменились они или нет. Чтобы решить эту проблему, я изменил отображение для прямого доступа к полю. См. this в Hibernate, который также применим к NHibernate.
Это новое (Свободное) отображение:

HasMany(x => x.Parameters)
       .Cascade.All()
       .Access.CamelCaseField(Prefix.Underscore);
0 голосов
/ 05 мая 2010

Другое решение - присоединиться Получить отношения, если вы знаете, что будете связывать их с данными. Например. добавить .SetFetchMode ("Люди", FetchMode.Join). NHibernate должен возвращать только доменные объекты, так как ни один из них не должен загружаться с отложенной загрузкой.

0 голосов
/ 28 мая 2009

Я не использую свои доменные объекты непосредственно в представлениях. Вместо этого я использую шаблон MVVM и создаю подходящие модели представлений, которые содержат объекты без прокси.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...