Dao, Service ,Vo, Mapper

1.DAO(인터페이스)
데이터 베이스에 접근 하는 객체(DB의 data에 접근하는 객체), 단일 데이터의 접근 및 갱신의 개념이다.
프로젝트의 Service 모델과 DB를 연결하는 역할

사용자는 자신이 필요한 Interface를 DAO에게 던지고 DAO는 이 인터페이스를
구현한 객체를 사용자에게 편리하게 사용 할 수 있도록 반환

DB에 대한 접근을 DAO가 담당하도록 하여 데이터베이스 접근을 DAO에서만하게 되면

다수의 원격호출을 통한 오버헤드를 VO나 DTO를 통해 줄일 수 있고
다수의 DB 호출문제를 해결할 수 있다.

또한 단순히 읽기만 하는 연산이므로 트랜잭션 간의 오버헤드를 감소시킨다.

1-1.DAO와 Repository의 차이
두 개념은 비슷하지만 다른점이 있다.
Repository는 Entity 객체를 보관, 관리
Dao는 데이터에 접근하도록 DB접근 로직을 모아둔 객체

※Spring JPA에서는 DB에 데이터를 CRUD하는 Repository 객체들이 DAO다.

2.DAO implement
싱글톤 패턴이다.
private로 기본 생성자 선언한다.
private static으로 Dao를 선언한다.
public static으로 getDao를 만들어서 다른곳에서 쓸 수 있게 한다.
Dao에 만들어 둔 함수를 override한다.

2-1.DAO와 DAO implement
DAO(인터페이스)
DAO implement(클래스)

Dao로 만들어서 진행할 경우 해당 인터페이스를 구현한 클래스가 내부적으로 생성해서 진행하기 때문에
설정 값 기반으로 움직이는 것이다.

DaoImpl은 자신이 직접 구현할 클래스이기 때문에 빈을 일일이 지정해주어야 한다.

Dao로 하면 설정되어 있는 Mapper를 SqlSessionTemplate에 설정한뒤 이를 자동으로 자기가 Injection한 클래스를

자신이 알아서 생성해주는 것이고,
DaoImpl의 경우는 위의 행동을 프로그래머가 직접 해줘야 한다.

3.Service
Spring MVC패턴의 핵심은 분산이다.

View는 자신이 요청할 Controller를 알아야 하고,
Controller는 넘어온 매개변수를 이용하여 Service객체를 호출한다.
DAO는 ibatis/Mybatis등 데이터베이스 Connection을 통해 데이터를 주고 받는 역할이다.
Service는 Pojo객체로 구성된다.
(Request/ Response를 받지 않고, DB와 데이터를 주고 받지 않는다.)

DAO는 단일 데이터 접근 로직이기 때문에
여러번 DB접근이 필요한 경우 병렬식으로 동시 접근이 가능한 Service는
여러개의 DAO를 묶은 트랜잭션이 생성되고 Service는 트랜잭션의 단위가 된다.

실무에서 Service 특징을 제대로 못살리는 경우가 많아 Service Interface 하나에 Impl 하나 생성해서 끝마치는 경우가 많지만, 그렇다고 해서 Service를 과소평가해서는 안된다.

재사용이라는 Spring의 큰 장점은 Service가 중요한 작용점이다.

4.Service implement

Service(interface)와 Service implement(class) 구조를 사용하는 이유
프로젝트를 만들 때 MemberService와 같이 서비스를 인터페이스로 설계하고,
MemberServiceimpl 라는 구현체인 클래스를 생성해서 사용하는 방식으로 대부분 설계를 한다.

인터페이스와 구현체를 분리하면 구현체를 독릭적으로 확장 할 수 있고,
구현체 클래스를 변경, 확장을 하더라도 클래스를 사용하는 클라이언트의 코드에 영향을 주지 않게 하기 위함이다.

객체지향의 특징중 하나인 추상화를 통한 구현방식은 OCP 원칙을 잘 실현해주는 설계 방식이다.

※ OCP (Open Closed Principle)
개방, 폐쇄 원칙이라고 하며 '소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.'는 프로그래밍 원칙


5.Vo(Value Object)
단순히 데이터 값을 전달하기 위한 용도로 사용되는 객체
도메인 주도 설계에서 이야기하는 값 객체

VO의 특성
1.불변성
생성자를 통해 한 번 생성되면 그 이후에 내부의 값을 변경할 수 없어야 한다.
VO객체는 사용 도중에 값을 변경할 수 없으며 이를 보장하기 위해
Setter를 허용하지 않고, GC에 의해 폐기될 때까지 불변한다.

불변성의 장점
Hassle-free Sharing(번거롭지 않은 공유)
사용 도중에 값이 변경되지 않음으로 참조하여 공유가 가능하고,코드의 복잡성과 부하를 감소시킨다.

 

Improved Semantics(향상된 의미)
명확한 이름과 동작을 가진다.
이를 위해 VO의 초기 클래스에 생성자와 private 인스턴스 변수만 있어야 한다.

2.값의 동등성
객체를 만들어주고 다른 참조변수를 가지고있을때
다른 객체이지만 동일한 내부 값을 가지고 있을 때 동등하다고 판단한다.
이때, 같은 값을 가지고 있는지를 판단하는 메서드를 만들거나 equals()와 hashcode()
함수를 재정의하여야 한다.

3.유효성 검사
VO는 유효하지 않은 값 객체를 만들 수 없도록 유효성 검사를 시행해야 한다.
유효성 검사는 생성 시간에 이루어져야 하며 필드중 하나라도 유효하지 않다면
적절한 예외를 던져야하는데, 이러한 검증은 도메인 제약 조건을 의미있고 명시적인 방식으로 표현하는데 유용하다.

※도메인을 설계할때, 원시 타입 값을 사용하지 않고 Value Object로 포장하여 객체 간의 역할을 나눈다.


6.Mapper
Repository와 Mapper를 비교할때 가장 작은 단위
Mapper는 .xml 과 같이 sql문을 정의해놓은 파일과 많이 사용한다.
SQL문을 정의하고 그 결과를 정해놓은 모델에 매핑시키는 ibatis방식에서 사용한다.
SQL문을 메소드로 매핑 = .xml을 java(class)에 매핑 시키는 것

정의해놓은 SQL과 개발에 사용하는 메소드를 연결하고 결과 값을 정의해놓은 타입으로 연결시켜준다.

Mapper 인터페이스 
Mapper 인터페이스는 Mapping 파일에 기재된 SQL을 호출하기 위한 인터페이스이다.
따라서 Mapping 파일에 있는 SQL을 자바 인터페이스를 통해 호출할 수 있도록 해준다. 

Repository와 Mapper

Repository는  Mapper를 포함하고 있다.
Repository는 Dao다.
Dao는 데이터에 접근하도록 DB접근 로직을 모아둔 객체

Mapper
위에서 설명한 것처럼 sql을 메소드로 쓰기 위해, sql 결과를 정의해놓은 모델로 매핑하기 위한 이름 그대로의 매퍼이다.

Repository
위의 매퍼들을 포함해서 mapper처럼 sql을 메소드랑 매핑해서 쓰든 아니든 db를 조회 및 조작하는 것에 중점을 둔 개념이다.
@Repository를 붙이면 해당 객체는 자동으로 빈 등록이 되고 DI에 쓰일 수 있다

Mapper와 Repository의 차이 정리
MVC에서 repository, mapper를 적용해보면 아래와 같이 구현하고자 하는 구조에 따라서 유동적으로 선택해서 사용하면 된다.
Mapper만 썼으니 틀리고 Mapper 클래스 없이 Repository만 썼으니 틀린 건 아니다.

- Controller -> Service -> Repository -> mapper.xml

- Controller -> Service -> Repository -> Mapper -> mapper.xml

- Controller -> Service -> Mapper -> mapper.xml