Value 개체에는 얼마나 많은 비즈니스 논리가 포함되어야 합니까?

Question

내가 존경하는 한 멘토는 단순한 빈은 시간 낭비이며 가치 객체에는 유용할 비즈니스 로직이 '반드시' 포함되어야 한다고 제안했습니다.

또 다른 사람은 그러한 코드는 유지 관리가 어렵고 모든 비즈니스 로직을 외부화해야 한다고 말합니다.

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

Answer 1

그 사람한테 전화하는 게 좋을 것 같아 객체 전송 또는 데이터 전송 객체(DTO).

이전에는 이 동일한 j2ee 패턴을 'Value object'라고 불렀으나 이것과 혼동되었기 때문에 이름을 변경했습니다.

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

귀하의 질문에 대답하기 위해 저는 DTO에 표시상의 이유로 필요한 논리인 최소한의 논리만 적용하겠습니다.

더 좋은 점은 데이터베이스 기반 웹 애플리케이션에 대해 이야기하고 있다면 핵심 j2ee 패턴을 뛰어넘어 다음을 사용할 것입니다. 최대 절전 모드 아니면 그 자바 지속성 API 관계의 지연 로딩을 지원하는 도메인 모델을 생성하고 이를 뷰에서 사용합니다.

참조 보기에서 세션 열기.

이런 방식으로 DTO 세트를 프로그래밍할 필요가 없으며 뷰/컨트롤러 등에서 사용할 수 있는 모든 비즈니스 로직을 갖게 됩니다.

Answer 2

데이터와 비즈니스 로직을 함께 두는 아이디어는 캡슐화를 촉진하고 내부 상태를 다른 개체에 최대한 적게 노출시키는 것입니다.이렇게 하면 클라이언트는 구현이 아닌 인터페이스에 의존할 수 있습니다.참조 "묻지 말고 말하고" 원리와 데메테르의 법칙.캡슐화를 사용하면 데이터의 상태를 더 쉽게 이해할 수 있고, 코드를 더 쉽게 읽을 수 있으며, 클래스를 더 쉽게 분리할 수 있고, 일반적으로 단위 테스트도 더 쉽게 할 수 있습니다.

비즈니스 로직 외부화 (일반적으로 "서비스"또는 "관리자"클래스로) "이 데이터는 어디에 사용됩니까?"와 같은 질문을합니다. 그리고 "어떤 주에있을 수 있습니까?" 대답하기가 훨씬 어렵습니다.그것은 또한 객체에 싸여 있는 절차적 사고 방식이기도 합니다.이로 인해 다음이 발생할 수 있습니다. 빈혈 도메인 모델.

외현화 행동이 항상 나쁜 것은 아닙니다.예를 들어, 서비스 계층 도메인 개체를 조정할 수 있지만 상태 조작 책임은 맡지 않습니다.또는 입력 양식에 잘 매핑되는 DB에 대한 읽기/쓰기를 주로 수행하는 경우 도메인 모델이 필요하지 않거나 그에 수반되는 고통스러운 개체/관계형 매핑 오버헤드가 전혀 필요하지 않을 수도 있습니다.

전송 개체는 비즈니스 로직을 노출하지 않고 호출 계층에 필요한 최소 상태 정보를 제공하여 아키텍처 계층을 서로(또는 외부 시스템)에서 분리하는 역할을 하는 경우가 많습니다.

예를 들어 뷰에 대한 정보를 준비할 때 유용할 수 있습니다.뷰에 필요한 정보만 제공하고 다른 정보는 제공하지 않아 뷰가 집중할 수 있도록 합니다. 어떻게 정보를 표시하는 것이 아니라 무엇 표시할 정보.예를 들어 TO는 여러 데이터 소스의 집합일 수 있습니다.

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

그러나 많은 Transfer Object와 종종 많은 중복과 관련된 오버헤드도 있습니다.내가 참여했던 일부 프로젝트는 기본적으로 다른 도메인 개체를 미러링하는 TO(나는 안티 패턴으로 간주함)로 끝났습니다.

Answer 3

때에 따라 다르지.

아, 제가 방금 진부한 말을 꺼냈나요?

객체를 디자인할 때 묻는 기본 질문은 다음과 같습니다.객체의 데이터를 관리하는 논리는 무엇입니까? 다른 또는 똑같다 다른 객체에 의해 사용/소비될 때?

서로 다른 사용 영역에서 서로 다른 논리가 필요한 경우 이를 외부화하세요.물체가 어디로 이동하든 동일하다면 클래스와 함께 배치하세요.

Answer 4

개인적으로 선호하는 것은 모든 비즈니스 논리를 도메인 모델 자체, 즉 "진정한" 도메인 개체에 두는 것입니다.따라서 데이터 전송 개체가 생성되면 대부분 도메인 개체의 (불변) 상태 표현이므로 비즈니스 논리가 포함되지 않습니다.복제 및 비교를 위한 메서드가 포함될 수 있지만 비즈니스 논리 코드의 핵심은 도메인 개체에 유지됩니다.

Answer 5

코로스가 말한 것.

Value Object := 돈이나 날짜 범위와 같이 동일성이 신원에 기반하지 않는 작고 단순한 개체입니다.

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

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

Answer 6

나는 Panagiotis의 의견에 동의합니다:보기 패턴의 열린 세션은 DTO를 사용하는 것보다 훨씬 낫습니다.다르게 말하면, 뷰 레이어에서 도메인 개체(또는 그 일부 복합물)를 아래로 트래피킹하는 경우 애플리케이션이 훨씬 더 간단하다는 것을 알았습니다.

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

Java가 아닌 API가 이러한 문제를 처리하는 방법을 조사하는 것이 마음에 들지 않는다면 Ruby 서버 페이지가 도메인 모델과 직접 작동하고 해당 연결을 탐색할 수 있도록 하는 Rails의 활성 레코드를 살펴볼 가치가 있습니다.