2010-06-16 5 views
1

직렬화에 대한 많은 책을 읽고 DTO를 만들려고 결정했습니다. 더 많은 독서 후에, 나는 AutoMapper를 사용하기로 결정했다.NHibernate를 사용하면 INHibernateProxy를 어떻게 만들 수 있습니까?

내가 뭘하고 싶은지 부모 (쉽게 충분히)를 변환하고 그들이 ValueResolvers 다음과 같은 짓을했는지, 그들이 초기화되었을 경우 엔티티 속성을 변환합니다. 그것은 완벽하게 작동합니다). 이 부분은 작동합니다. 내가 초기화되지 않은 엔티티, 엔티티로 다시 DTO를 변환 할 때

public class OrderItemResolver : ValueResolver<Order, OrderItem> 
{ 
    protected override OrderItem ResolveCore(Order source) 
    { 
     // could also use NHibernateUtil.IsInitialized(source.OrderItem) 
     if (source.OrderItem is NHibernate.Proxy.INHibernateProxy) 
      return null; 
     else 
      return source.OrderItem; 
     } 
    } 
} 

, 나는 엔티티가 액세스하고자하는 경우에 따라서는 그, 그것을 할 수있는 프록시를 만들려고합니다. 그러나, 나는 프록시를 만드는 방법을 알아낼 수 없습니다. 그게 관련성이 있다면 캐슬을 사용하고 있습니다.

나는 운이없는 것들을 잔뜩 시도했다. 아래 코드는 혼란 스럽습니다. 왜냐하면 주로 내가 무엇을해야하는지 모른 채 무작위로 노력하고 있기 때문입니다. 아무도 제안이 없나요?

public class OrderItemDTOResolver : ValueResolver<OrderDTO, OrderItem> 
{ 
    protected override OrderItem ResolveCore(OrderDTO source) 
    { 
     if (source.OrderItem == null) 
     { 
      //OrderItem OrderItem = new ProxyGenerator().CreateClassProxy<OrderItem>(); // Castle.Core.Interceptor. 

      //OrderItem OrderItem = new ProxyGenerator().CreateClassProxy<OrderItem>(); 
      //OrderItem.Id = source.OrderItemId; 

      //OrderItem OrderItem = new OrderItem(); 
      //var proxy = new OrderItem() as INHibernateProxy; 
      //var proxy = OrderItem as INHibernateProxy; 
      //return (OrderItem)proxy.HibernateLazyInitializer 
      //ILazyInitializer proxy = new LazyInitializer("OrderItem", OrderItem, source.OrderItemId, null, null, null, null); 
      //return (OrderItem)proxy; 
      //return (OrderItem)proxy.HibernateLazyInitializer.GetImplementation(); 

      //return OrderItem; 

      IProxyTargetAccessor proxy = new Castle.Core.Interceptor. 

      var initializer = new LazyInitializer("OrderItem", typeof(OrderItem), source.OrderItemId, null, null, null, null); 
      //var proxyFactory = new SerializableProxyFactory{Interfaces = Interfaces, TargetSource = initializer, ProxyTargetType = IsClassProxy}; 

      //proxyFactory.AddAdvice(initializer); 
      //object proxyInstance = proxyFactory.GetProxy(); 
      //return (INHibernateProxy) proxyInstance; 
      return null; 


      //OrderItem.Id = source.OrderItemId; 
      //return OrderItem; 
     } 

     else 
      return OrderItemDTO.Unmap(source.OrderItem); 
    } 
} 

덕분에, 에릭

은 어쩌면 내가 이상을 복잡. 이것은 작동하는 것 같습니다. 누구도 그걸로 어떤 문제를 볼 수 있습니까?

public class OrderItemDTOResolver : ValueResolver<OrderDTO, OrderItem> 
{ 
    protected override OrderItem ResolveCore(OrderDTO source) 
    { 
     if (source.OrderItem == null) 
      return NHibernateSessionManager.Instance.Session.GetISession().Load<OrderItem>(source.AgencyId); 

     else 
      return OrderItemDTO.Unmap(source.OrderItem); 
    } 
} 

답변

1

답변이 "하지"거나 적어도 "하지 말아야 할 경우"중 하나 일 수 있습니다. DTO를 NHibernate 맵핑 된 오브젝트에 직접 맵핑하는 경우 맵핑 오브젝트를 도메인 오브젝트로 실제로 사용하지 않고 데이터를 데이터 베이 스 안팎으로 밀어 넣을 수있는 멋진 방법입니다. 이것은 물론 당신이하는 모든 것일지도 모르지만 과거에 나 자신을 해본 결과 두 방향으로 동일한 DTO 데이터 형식을 사용하는 것이 문제가되는 것으로 나타났습니다. 교차 프로세스를 진행하는 경우 서비스를 (유지하기 어려운) CRUD 계층으로 전환했습니다. 같은 과정에 있다면 DTO로 불필요한 데이터 셔플을하고있는 것입니다.

DTO를 보내면 좋지만 클라이언트가 실제로 필요로하는 것과보다 밀접하게 정렬 된 형식으로 데이터를 투영하는 것이 좋습니다. 다시 돌아 오는 것은 실제 작업을 수행하는 데 필요한 데이터 만 표시하는 특정 DTO (Command 객체, 본질적으로)에서 더 잘 표현됩니다. 몇 가지 자동 특성으로 그들은 사소한 것입니다. 그런 다음 필요한 정보만으로 필요한 조치를 수행하고 수행중인 조치에 적합한 형식으로 수행하는 비즈니스 메소드를 가질 수 있습니다. 요즘 AutoMapper를 사용하는 것은 들어오는 DTO를 도메인 메소드가 사용할 수있는 유형으로 변환하는 것입니다.

매핑 된 개체의 공용 설정자는 유효성 검사없이 개체가 임의의 코드에서 조작 될 수 있으므로 바람직하지 않습니다. 이것은 그것들을 수정하면 잘못된 상태로 남을 수 있음을 의미합니다.

위의 내용에 별다른 관심이없는 경우 개별 인스턴스를로드하는 방식으로 잠재적 인 성능 문제 인 많은 개별 데이터베이스로드를 수행 할 수 있습니다.

+0

나는이 접근 방식에 대한 큰 팬이 아니므로, "do not"응답을 확실히 이해합니다. 제한된 시나리오에서이 작업을 수행하려고합니다. 이 작업을 수행하려고하는 이유는 고전적인 ASP.NET 사이트에서 작업하고 있기 때문입니다. 내가 판매하는 제품은 매우 맞춤 설정할 수 있습니다. 일부 옵션을 선택하고, 다른 옵션을 활성화하며, 모두 가격을 결정합니다. 엔티티를 채우면 가격을 책정하는 함수를 호출 할 수 있습니다. 가격 책정은 옵션을 기반으로 동적 가격 책정표를 얻기 위해 데이터베이스로 이동합니다. 현재 지루한 각 게시물/콜백에서 엔티티를 다시 작성하고 있습니다. 나는 더 자동적 인 무언가를 기대하고 있었다. – Eric

+0

그건 일이 더 문제가되지 않습니다.가능한 옵션 : - 가격 결정 방법을 캡슐화하는 쿼리 개체를 사용하십시오. 나는 DetachedCriteria를 반환하는 객체를 사용하여 MVC의 컨트롤러가 페이징, 정렬 등을 추가 할 수 있도록합니다. 각 상황에 맞게 사용자 정의 할 수있는 기본 클래스를 만들 수 있습니다. - 가격 산정 방식을 산정하십시오. 물론 많은 옵션이 있으므로 매우 큰 데이터 세트라고 할 수 있습니다. NoSQL DB가 처리 할 수있는 무언가 일 수도 있습니다. 나는 여전히 1 : 1 DTO와 매핑 된 객체 배열에 강하게 반대 할 것입니다. 그것은 단지 문제를 요구하고 있습니다. – AbstractCode

+0

이것은 제가 조금 상식이 될 수있는 계승 된 시스템입니다. 가격은 약 10 개의 서로 다른 테이블에 걸쳐 있으며 광범위한 데이터 액세스가 필요합니다. 우리는 viewstate를 기반으로 엔티티를 재구성하는 작업을하고 있지만,보기 흉합니다. – Eric

관련 문제