1. POJO
POJO(Plain old java object)란?
특별한 제한에 종속되지 않고, class path를 필요로 하지 않는 일반적인 java object를 의미합니다.
"We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely."
우리는 왜 사람들이 자기들 시스템에 일반적인 오브젝트를 사용하는 것에 반대하는지 궁금했고, 그 이유는 단순한 오브젝트에 멋진 이름이 없기 때문이라고 결론을 지었습니다. 그래서 우리는 멋진 이름을 지었고, 매우 인기를 얻었습니다.
java오브젝트 모델, 컨벤션 또는 프레임워크를 따르지 않는 java오브젝트를 나타냅니다.
스프링 애플리케이션 = POJO를 이용해서 만든 애플리케이션 로직 + POJO가 어떻게 관계를 맺고 동작하는지 정의해 놓은 설계 정보
스프링의 주요기능 IOC, AOP, PSA는 애플리케이션을 POJO로 개발할 수 있게 해주는 기술들이다.
POJO의 조건
1. 특정 규약에 종속되지 않는다.
특정 환경에 종속되면 객체지향적인 설계기법 적용이 어려지고 다른 환경으로 이전이 어려워진다.
-
특정 환경에 종속되지 않는다.
HttpServletRequest나 HttpSession과 관련된 API를 직접 이용한다면 다른 환경에서 사용하기 어려워 지고, 비즈니스 로직과 기술적인 내용을 담은 웹정보 코드가 섞여 이해하기 어려워진다. 때문에 테스트하기도 어려워 진다. -
단일 책임 원칙을 지키는 클래스
단숞히 위 원칙을 지켰다고 POJO라고 할 수 없다. 책임과 역할을 지키며 객체지향적인 원리에 충실하며, 특정 환경과 규약에 종속되지 않아 필요에 따라 재사용될 수 잇는 방식으로 설계된 오브젝트여야 한다.
2. 싱글톤 패턴
애플리케이션이 시작될 때 어떤 클래스가 최초 한번만 메모리를 할당하고 그 메모리에 인스턴스를 만들어 사용하는 디자인패턴, 커넥션 풀, 스레드 풀, 디바이스 설정 객체 등의 경우, 인스턴스를 여러 개 만들게 되면 자원이 낭비되거나 오류가 발생한다. 그래서 오직 하나만 생성하고 그 인스턴스를 사용하도록 하는게 이 패턴의 목적이다.
구현
하나의 인스턴스를 유지하기 위해 인스턴스 생성에 특별한 제약이 필요한다. new로 생성할 수 없도록 생성자에 private 접근 제어자를 지정하고, 유일한 단일 객체를 반환할 수 있도록 정적 메소드를 지원해야 한다.
public class Singleton {
private static Singleton singleton;
private Singleton() {}
public static Singleton getInstance() {
if (singleton == null) {
singleton = new Singleton();
}
return singleton;
}
}이 코드는 위험하다. 멀티스레드 환경에서 문제가 발생한다. 동시에 접근하면 인스턴스가 두 개 생성될 수 있다. 그렇기 때문에 getInstance() 메소드를 동기화시켜야 한다.
public class Singleton {
private static Singleton singleton;
private Singleton() {}
public static synchronized Singleton getInstance() {
if (singleton == null) {
singleton = new Singleton();
}
return singleton;
}
}synchronized 를 사용하면 성능상에 문제가 있다.
public class Singleton {
private static volatile Singleton singleton;
private Singleton() {}
public static Singleton getInstance() {
if (singleton == null) {
synchronized (Singleton.class) {
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
}Double Checking Locking를 사용하여 동기화 되는 영역을 줄일 수 있다. 그러나 이 코드는 멀티코어 환경에서 동작할 때, 하나의 CPU를 제외하고 다른 CPU가 lock에 걸리게 된다.
public class Singleton {
private static volatile Singleton singleton = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return singleton;
}
}클래스 로딩되는 시점에 미리 객체를 생성해두고 그 객체를 반환한다.
3. JPA
ORM(Object-Relation Mapping)
객체 관계 매핑, 객체지향적인 JAVA와 관계형 데이터베이스 테이블 간에 불일치가 존재한다. ORM은 객체 관계를 바탕으로 SQL을 자동으로 생성하여 데이터베이스를 다룬다.
장점
1. 객체 지향적인 코드 작성으로 더 직관적이고, 비즈니스 로직에 더 집중할 수 있다.
- SQL 쿼리문이 아닌 직관적인 코드(객체)로 데이터를 조작할 수 있어 개발자가 객체 모델로 프로그래밍 하는데 더 집중 할 수 있도록 도와준다.
- 객체에 대한 코드로 별도로 작성하기 때문에 코드의 가독성을 올려준다.
- SQL의 절차적이고 순차적인 접근이 아닌 객체 지향적 접근으로 인해 생산성이 증가한다.
- 재사용 및 유지보수의 편리성이 증가한다.
- ORM은 독립적으로 작성되어 있고 해당 객체들을 재활용할 수 있다.
- 모델에서 가공된 데이터(DTO)를 컨트롤러에 의해 뷰와 합쳐지는 형태로 디자인 패턴을 견고하게 다지는데 유리하다.
- 매핑정보가 명확하여, 개체-관계 모델을 보는 것에 대한 의존도를 낮출 수 있다.
- DBMS 에 대한 종속성이 줄어든다.
- 객체 관계를 바탕으로 SQL을 자동으로 생성하기 때문에 RDBMS의 데이터 구조와와 JAVA 객체지향 모델간의 간격을 좁힐 수 있다.
- ORM 솔루션은 DB에 종속적이지 않다.
- 프로그래머는 객체에 집중함으로 극단적으로 DBMS를 교체하는 거대한 작업에도 비교적 적은 리스크와 시간이 소요된다.
- 자바에서 가공할 경우 equals, hashCode의 오버라이드 같은 자바와 기능을 이용할 수 있고, 간결하고 빠른 가공이 가능하다.
단점
1. 완벽하게 ORM으로만 서비스를 구현하기 어렵다.
- 사용하기에는 쉽지만 설계하는데에는 매우 신중해야한다.
- 프로젝트의 복잡성이 커질경우 난이도 또한 올라갈 수 있다.
- 잘못 구현된 경우에 속도 저하 및 일관성이 무너지는 문제점이 발생할 수 있다.
- 잘못 구현된 경우에 속도 저하 및 일관성이 무너지는 문제점이 발생할 수 있다.
- 다시 객체로 바꿔야하며, 그 과정에서 생산성 저하나 리스크가 많이 발생 할 수 있다.
ORM 프레임워크 중에서 하이버네이트 프레임워크를 가장 많이 사용한다.
JPA(Java Persistence API)
JPA(Java Persistance API)는 자바 진영의 ORM 기술 표준이다. 자바 진영에서 하이버네이트라는 오픈소스 ORM 프레임워크를 기반으로 새로운 자바 ORM 기술표준을 만들었는데 그것이 JPA이다. JPA는 라이브러리가 아닌 자바 어플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스이다. 하이버네이트는 JPA의 구현체이다.
Spring Data JPA
Spring 에서 JPA를 편리하게 쓰기 편하게 만들어놓은 모듈이다. JPA를 한 단계 더 추상화시킨 Repository라는 인터페이스를 제공함으로써 이루어진다.
- 공통 메서드가 아닐 경우에도 JPA가 메서드 이름을 분석하여 JPQL을 생성한다.
- 개발자는 repository에 인터페이스만 작성해도 개발을 완료할 수 있도록 지원해준다.
- Spring Data JPA가 구현 객체를 동적으로 생성하여 주입해준다.
- CRUD 처리를 위한 공통 인터페이스를 제공한다.
