Value 개체에 포함될 비즈니스 로직의 양은 얼마입니까?

Question

존경하는 사람 중 한 명은 단순한 빈이 시간 낭비임을 암시합니다. 가치 객체에는 유용한 비즈니스 로직이 있어야합니다.

다른 사람은 이러한 코드를 유지하기 어렵고 모든 비즈니스 로직을 외부화해야한다고 말합니다.

나는이 질문이 주관적이라는 것을 알고 있습니다. 어쨌든 묻기 - 더 많은 관점에서 답을 알고 싶습니다.

Answer 1

Transfer Objects 또는 Data transfer objects (DTO)으로 전화하는 것이 좋습니다.

초 같은 J2EE 패턴이 '값 객체'라고하지만

http://dddcommunity.org/discussion/messageboardarchive/ValueObjects.html

귀하의 질문에 대답하기 위해이 혼동했기 때문에 그들이 이름을 변경했다, 난 단지 내 DTO들에게 최소한의 논리를 넣어 것입니다, 표시상의 이유로 필요한 논리

데이터베이스 기반 웹 응용 프로그램에 대해 이야기 할 경우 코어 j2ee 패턴을 넘어서서 Hibernate 또는 Java Persistence API을 사용하여 관계의 지연로드를 지원하는 도메인 모델을 만들고이를 뷰에서 사용하십시오.

Open session in view을 참조하십시오. 이런 식으로

, 당신은 DTO들의 집합을 프로그램 할 필요가 없습니다 당신은 Korros 말했다 무엇 등 귀하의 의견/컨트롤러

Answer 2

개인적인 선호는 모든 비즈니스 로직을 도메인 모델 자체, 즉 "실제"도메인 개체에 넣는 것입니다. 따라서 데이터 전송 객체가 생성되면 대부분 도메인 객체의 (불변 인) 상태 표현이므로 비즈니스 로직을 포함하지 않습니다. 그러나 복제 및 비교를위한 메소드를 포함 할 수 있지만 비즈니스 로직 코드의 내용은 도메인 객체에 남아 있습니다.

Answer 3

에 따라 다릅니다.

나는 단지 진부한 말을 외면 했습니까?

객체를 설계를 요구하는 기본적인 질문은 : 개체의 데이터에 적용되는 논리가 다른 또는 될 것 같은 사용하는 경우/다른 객체에 의해 소비?

다른 사용 영역이 다른 논리를 요구하면이를 외부화하십시오. 물건이 어디로 옮겨 지더라도 똑같다면, 그것을 수업과 함께 배치하십시오.

Answer 4

에서 사용할 수있는 모든 비즈니스 로직을 가지고있다.

값 개체 : 동일성이 신원을 기반으로하지 않는 돈이나 날짜 범위와 같은 작은 단순 개체입니다.

DTO : 메서드 호출 수를 줄이기 위해 프로세스간에 데이터를 전달하는 개체입니다.

마틴 파울러 (Martin Fowler)가 제안한 정의이며, 나는 그것을 대중화하고 싶습니다.

Answer 5

데이터와 비즈니스 로직을 결합하는 개념은 캡슐화를 촉진하고 가능한 한 다른 내부 상태를 다른 개체에 표시하는 것입니다. 따라서 클라이언트는 구현보다는 인터페이스에 의존 할 수 있습니다."Tell, Don't Ask" 원칙과 Law of Demeter을 참조하십시오. 캡슐화를 통해 데이터 상태를 이해하고 코드를 읽기 쉽고 수업을 분리하기 쉽고 일반적으로 단위 테스트를 더 쉽게 수행 할 수 있습니다.

외부 비즈니스 로직 (일반적으로 "서비스"또는 "관리자"클래스)은 "이 데이터는 어디에 사용됩니까?"와 같은 질문을합니다. "어떤 주에있을 수 있습니까?" 대답하기가 훨씬 어렵습니다. 그것은 또한 절차 적 사고 방식으로, 대상에 싸여 있습니다. 이로 인해 anemic domain model이 될 수 있습니다.

외부화 동작이 항상 나쁜 것은 아닙니다. 예를 들어, service layer은 도메인 객체를 조정할 수 있지만 상태 조작 책임을 대신 할 수는 없습니다. 또는 대부분 입력 양식에 매핑되는 DB에 대한 읽기/쓰기 작업을 수행 할 때 도메인 모델이 필요하지 않거나 객체/관계형 매핑 오버 헤드가 전혀 필요하지 않을 수도 있습니다.

전송 객체는 비즈니스 로직을 노출시키지 않으면 서 호출 계층에 필요한 최소 상태 정보를 제공하여 서로 다른 아키텍처 계층 (또는 외부 시스템)과의 연결을 끊는 역할을합니다.

이 유용 할 수 있습니다 예를 들어 때 뷰에 대한 정보를 준비하는 것이 무엇보다는, 정보를 표시하는 방법에 집중할 수 있도록 단지, 뷰에게가 필요한 정보, 그리고 아무것도를 제공 표시 할 정보. 예를 들어, TO는 여러 데이터 소스를 집계 한 것일 수 있습니다.

장점 중 하나는보기와 도메인 개체가 분리되어 있다는 것입니다. JSP에서 도메인 객체를 사용하면 도메인을 리팩터링하기가 어려워지고 getter와 setter의 무차별적인 사용이 촉진됩니다 (따라서 캡슐화가 중단됩니다).

그러나 많은 양의 전송 객체 및 종종 많은 중복을 갖는 오버 헤드도 있습니다. 내가 끝낸 프로젝트 중 일부는 기본적으로 다른 도메인 객체를 미러링합니다 (안티 패턴이라고 생각합니다).

Answer 6

나는 Panagiotis에 동의한다. 뷰 패턴의 열린 세션은 DTO를 사용하는 것보다 훨씬 낫다. 그렇지 않으면, 당신은 당신의 도메인 계층 (또는 그것의 복합체)에서 뷰 레이어의 모든 경로로 트래픽을 보내는 경우 애플리케이션이 훨씬 간단하다는 것을 알았습니다.

즉, HttpSession을 지속성 계층의 작업 단위와 일치시켜야하기 때문에 시작하기가 어렵습니다. 그런 다음 모든 데이터베이스 수정 (즉, 작성, 갱신 및 삭제)이 의도적인지 확인해야합니다. 즉, 뷰 레이어에 도메인 객체가 있고 필드가 수정되고 응용 프로그램 코드가 의도적으로 변경 사항을 저장하지 않고 수정 사항이 지속되는 경우는 바람직하지 않습니다. 처리해야 할 또 다른 문제는 트랜잭션 의미가 만족 스러운지 확인하는 것입니다. 일반적으로 하나의 도메인 객체를 가져오고 수정하는 것은 하나의 트랜잭션 컨텍스트에서 이루어지며 ORM 계층에 새 트랜잭션이 필요하지는 않습니다. 은입니다. 중첩 된 트랜잭션은 열린 첫 번째 트랜잭션 컨텍스트에 두 번째 트랜잭션 컨텍스트를 포함하려는 것입니다.

Java가 아닌 API가 이러한 문제를 처리하는 방법을 조사하는 데 신경 쓰지 않는다면 Ruby 서버 페이지가 도메인 모델과 직접 연동하여 연결을 통과 할 수 있도록하는 Rails의 Active Record를 살펴 보는 것이 좋습니다.