Add new attachment

Only authorized users are allowed to upload new attachments.

This page (revision-7) was last changed on 16-Dec-2014 01:09 by DongGukLee  

This page was created on 12-Dec-2014 19:27 by DongGukLee

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 281 added 88 lines
! 도메인 오브젝트를 사용하는 코드
* Category 오브젝트를 사용하는 메소드
%%information 리스트 9-10 %%
* 도메인 모델을 사용할 경우 calcTotalOfProductPrice 메소드를 공통으로 사용해서 합을 구할수 있다.
* 데이터 중심일 경우 매번 sum()함수를 사용하는 쿼리를 사용하거나 Map이나 List에서 값을 가져와서 계산하는 복잡한 처리과정을 거쳐야 한다.
! 도메인 오브젝트 사용의 문제점
* 일관된 의미를 가지고 유연하며 애플리케애션 전반에 공유가능한 도메인 모델로 정보를 다루면 장점이 많다.
** 코드를 이해하기 쉽고 로직 작성이 수월하다.
** 코드 재사용성이 높아지고 DAO는 더 작고 효율적으로 만들수 있다.
* 단점도 있다.
** 최적화된 SQL을 사용하는 대신에 성능적인 면에서 일정부분 손해를 볼수도 있다.
** DAO는 서비스 로직을 알지 못하기 때문에 필요한 칼럼만을 사용하기 보다는 범용적으로 칼럼을 다 나열하는 형태를 사용하게 된다.
** Product와 Category 중 Product 정보만 필요한 경우에도 Category 정보가 셋팅되면 낭비가 발생하거나 관계를 가진 오브젝트에 null 이 설정되기도 한다.
* 단점을 해결하기 위한 방법
** 지연된 로딩(Lazy Loading) 기법을 사용하면 일단 최소한의 오브젝트 정보만 읽어두고 관계하고 있는 오브젝트가 필요한 경우에만 동적으로 DB에서 다시 읽어온다.
** 이상적으로는 JPA, JDO, 하이버네이트, TopLink 와 같은 ORM을 사용하는 것이다. 이런 기술은 기본적으로 지연된 로딩 기능을 제공해서 도메인 오브젝트 생성을 최적화할수 있다.
! 빈약한 도메인 오브젝트 방식
* 도메인 오브젝트에 정보만 있고 정보를 활용하는 아무런 기능도 없다면 온전한 오브젝트라고 보기 힘들다. 이런 오브젝트를 빈약한 오브젝트라고 부른다. 흔히 VO라고 부르는거?
* 빈약한 도메인 오브젝트의 비즈니스 로직은 서비스 계층에 로직이 들어있다.
* 빈약한 도메인 오브젝트 방식의 한계는 거대 서비스 계층 방식과 유사하다. 서비스 계층의 메소드에 대부분의 비즈니스 로직이 있어서 로직의 재사용성이 떨어지고 중복 문제가 있다.
* 빈약한 도메인 오브젝트 방식
%%information 그림 9-20 %%
! 풍성한 도메인 오브젝트 방식
* 풍성한 도메인 오브젝트 또는 영리한 도메인 오브젝트는 빈약한 도메인 오브젝트의 단점을 극복하고 객체지향적인 특징을 잘 사용할수 있도록 해준다.
* 자신의 정보를 활용하는 로직을 담은 도메인 오브젝트
%%information 리스트 9-11 %%
* 서비스 계층에서 도메인 오브젝트로 로직을 가져왔기 때문에 재사용이 편리하다.
* 서비스 코드를 줄어들고 도메인 오브젝트는 그자체가 역할이 커진다.
* 자체 로직을 가진 Category 를 사용하는 코드
%%information 리스트 9-13 %%
* 도메인 오브젝트는 DAO 오브젝트를 DI 받을수 없다.
* 도메인 오브젝트는 스프링이 관리하는 빈이 아니기 때문이다.
* 수식계산이나 조건에 다른 데이터 변경이나 자신이 가진 정보에 대한 분석 같은 일부 제한된 로직만 도메인 오브젝에 넣고 DAO나 서비스 계층에 의존하는 로직은 넣지 않는다.
* 풍성한 도메인 오브젝트 방식
%%information 그림 9-21 %%
! 도메인 계층 방식
* 풍성한 도메인 모델이라 하더라도 일부 제한적인 로직만을 담을수 있다.
* 도메인 오브젝트가 스스로 필요한 정보를 DAO를 통해 가져오고 생성이나 변경이 일어나면 직업 DAO에 변경사항을 반영해달라고 요청할수 없을까.?
* 도메인 오브젝트들이 하나의 독립적인 계층을 이뤄서 서비스 계층과 데이터 엑세스 계층 사이에 존재하게 한다.
* 도메인 오브젝트가 독립적인 게층을 이뤄서 발생하는 특징
## 도메인에 종속적인 비즈니스 로직의 처리는 서비스 계층이 아니라 도메인 계층의 오브젝트 안에서 진행된다.
## 도메인 오브젝트가 기존 데이터 엑세스 계층이나 기반 계층의 기능을 직접 활용할 수 있다.
* 스프링 빈이 아닌 도메인 오브젝트에 DI를 적용하기 위해서 AOP를 적용한다. AspectJ AOP를 사용하면 클래스의 생성자가 호출되면서 이 시점에 스프링 컨테이너에서 빈을 찾아 DI를 해준다. 이로인해 도메인 오브젝트나 서비스 계층이나 데이터 엑세스 계층의 오브젝트를 참조하면서 조금더 다양한 비즈니스 로직을 처리할 수 있다.
* 도메인 계층 적용으로 도메인 오브젝트와 서비스 계층간의 구분이 모호해지는 문제를 해결하기 위해서는 두가지 방법을 사용할 수 있다.
## 철저한 개발 가이드가 필요하다.
## 도메인 오브젝트는 도메인 계층을 벋어나지 못하게 한다. 도메인 계층을 벗어날때는 별도로 준비된 정보 전달용 오브젝트를 만든다. 이런 오브젝트를 데이터 전달을 위해 사용한다고 해서 DTO(Data Transfer Object) 라고 부른다. DTO는 상태의 변화를 허용하지 않고 읽기전용으로 만들기도 한다.
* 도메인 계층 방식
%%information 그림 9-22 %%
!! 9.3.4. 스프링 애플리케이션을 위한 아키텍처 설계
! 계층형 아키텍처
* 3계층 구조는 스프링을 사용하는 엔터프라이즈 애플리케이션에서 가장 많이 사용하는 구조다.
* 단 3계층은 논리적인 구분일 뿐이고 2계층으로 구성할수도 있으나 계층간의 구분은 명학하게 해야 한다.
! 정보 전송 아키텍처
* 스프링의 기본 기술에 가장 잘 들어맞고 쉽게 적용해볼수 있는 것은 오브젝트 중심 아키텍처의 도메인 오브젝트 방식이다.
! 상태 관리와 빈 스코프
! 서드파티 프레임워크, 라이브러리 적용
* 스프링이 지원하는 기술이란 무슨 의미일까?
## 첫째, 해당 기술을 스프링의 DI 패턴을 따라 사용할 수 있다.
## 둘째, 스프링의 서비스 추상화가 적용됐다.
## 셋째, 스프링이 지지하는 프로그래밍 모델을 적용했다.
## 넷째, 템플릿/콜백이 지원된다.
Version Date Modified Size Author Changes ... Change note
7 16-Dec-2014 01:09 9.958 kB DongGukLee to previous
6 15-Dec-2014 22:00 6.91 kB DongGukLee to previous | to last
5 15-Dec-2014 21:17 3.144 kB DongGukLee to previous | to last
4 15-Dec-2014 21:17 3.145 kB DongGukLee to previous | to last
3 15-Dec-2014 00:44 3.144 kB DongGukLee to previous | to last
2 12-Dec-2014 19:29 0.098 kB DongGukLee to previous | to last
1 12-Dec-2014 19:27 0.07 kB DongGukLee to last
« This page (revision-7) was last changed on 16-Dec-2014 01:09 by DongGukLee