서비스 계층에 DTO 객체를 전달하는 것은 나쁜 습관입니까?서비스 계층에 DTO 전달
지금 내 서비스 계층의 메소드는 다음과 같이 :
public save(MyEntity entity);
매핑 값을 DTO에서 비즈니스 엔티티 (MyEntity)으로는
프리젠 테이션 계층에서 이루어집니다하지만이에 메소드 서명을 변경하려면 :
public save(MyEntityDTO dto, String author);
그리고 DTO에서 비즈니스 엔티티로 매핑하면 서비스 계층에서 발생합니다.
EDIT : DTO에서 비즈니스 개체로 매핑 할 때 열린 최대 절전 모드 세션이 필요하므로 엔티티의 모든 변경 사항이 자동으로 플러시됩니다.
괜찮습니다. 모든 표준 3 계층 아키텍처가 좋습니다. Dataaccess는 데이터, 비즈니스 맵을 가져 와서 조작하고 프리젠 테이션에 표시합니다. 괜찮은 것은 아니지만, 범죄가 없다고 말하면서 데이터 액세스 모델을 프레젠테이션에 전달하려면이 시점에서 비즈니스 모델을 통과해야합니다. Btw. "DTO"는 무엇이든 의미 할 수 있으며 비즈니스 계층 모델은 DTO 일 수 있으며 데이터 액세스 모델은 DTO 일 수 있습니다. DTO는 대개 C#의 POCO입니다. 일반적으로 데이터베이스 엔티티와 응용 프로그램 주변의 데이터를 전달하는 도메인 모델을 나타내는 데이터 액세스 모델이 있습니다. 도메인 모델은 일반적으로 DTO (또는 POCO라고 함)입니다. 즉, Microsoft 음성에서는 완벽하게 직렬화가 가능하므로 모든 .net 구성 요소에 전달할 수 있습니다. xml, json 등등에 serialize 할 수도 있습니다 ...
서비스 레이어에 DTO 객체를 전달하는 것은 나쁜 습관입니까?
뿐만 아니라 당신은 DTO를 통과 할 수는 서비스 레이어에 객체,하지만 당신은 DTO 대신 비즈니스 엔티티 객체 패스 계층에 서비스를 제공한다.
귀하의 서비스는 DTO를 받고, 사업체에 매핑하여 저장소로 보내야합니다. 또한 저장소에서 비즈니스 엔티티를 검색하고이를 DTO에 맵핑하고 DTO를 응답으로 리턴해야합니다. 따라서 비즈니스 엔티티는 비즈니스 계층에서 벗어나지 않으며 DTO만이 수행합니다.
비슷한 질문에 대한 대답은 here입니다.
범죄가 아니라 모든 것이 달라지며 소프트웨어 계층 구조에 관한 기사를 읽으십시오 ... –