그래서이 asp.net 프로젝트에서 LLBLGen Pro 및 Spring.Net을 사용하여 비즈니스 계층을 데이터 저장소에서 분리합니다. 나는 또한 UI 레이어에서 PONOS 사용을 고려하고 있습니다. 이제 내 질문은 다음과 같습니다.ASP.NET, LLBLGen 및 서비스 레이어가있는 Spring.Net
풍부한 LLBLGen 엔터티 개체를 데이터 영역이나 서비스 계층의 Ponos에 매핑해야합니까? 데이터 레이어에서 처리하면 서비스 레이어에서 풍부한 기능을 모두 잃어 버리게됩니다. 아니면 Ponos 로의 매핑을 건너 뛰고 LLBLGen 엔티티를 끝까지 사용해야합니까? 나중에 그것을 올바르게 테스트하는 것이 더 어려울 경우?
누군가 내게 양쪽 접근법의 찬반 양론을 줄 수 있습니까?
감사
매핑과 LLBLGen 엔티티를 사용하는 거꾸로 당신은 매우 유용한을 가질 수 있도록, 엔티티가 데이터베이스 스키마에서 바로 생성 (또는 LLBL 3.x의에서 어떤 데이터베이스 스키마로) 얻을 수 있다는 것입니다 엔티티 모델을 몇 분 만에 확인하십시오. 단점은 엔티티가 LLBL 프레임 워크 클래스에서 상속되므로 비헤이비어/비즈니스 로직을 풍부하게 만드는 것이 어렵다는 것입니다. 일반적으로 biz 로직을 일련의 서비스로 설계하면 문제가되지 않습니다.
일반적으로 개체를 "빈혈"데이터 개체로 간주하므로 일반적으로 그러한 개체를 조롱하지 않습니다 (실제 이유가 없습니다).이 시나리오에서는 문제가 테스트되지 않습니다.
POCO에 매핑의 장점은 도메인/엔티티/DTO 개체의 디자인을 완벽하게 제어 할 수 있다는 것입니다. 원하는만큼 풍부하거나 빈약 할 수 있습니다. 단점은 POCO 클래스와 매핑을 디자인하고 코딩해야하며 LLBL 엔터티에 내장 된 변경 내용 추적과 같은 일부 기능을 잃게된다는 것입니다.
필자는 개인적으로 생성 된 엔티티 개체를 사용하도록 선택하지 않는다.