앜스토리 | 호기심 많은 개발자의 보물창고

이전 포스팅에서도 작성을 했지만, 스프링을 사용하지 않았을 때의 문제 세 가지를 꼽자면 다음과 같다. - 오브젝트의 생명 주기 문제 - 부품화 문제 - 기술 은닉과 부적절한 기술 은닉 문제 이러한 문제를 해결하지 않는 한 웹 애플리케이션은 리소스를 잘 이용하지 못하고, 테스트하기 어려우며, 확장이나 변경도 어려워질 것이다. 스프링은 이러한 문제를 해결하기 위해 태어난 컨테이너라고도 할 수 있다. 자세한 내용은 나중에 설명하겠지만, 스프링은 다음처럼 문제를 해결해줄 수 있다. - 오브젝트의 생명 주기 문제는 DI 컨테이너로 해결 - 부품화 문제는 DI 컨테이너로 해결 - 기술 은닉과 부적절한 기술 은닉 문제는 AOP로 해결 스프링은 Java/Java EE용 오픈 소스 프레임워크이고, 현재는 Pivotal ..

개발자의 수준을 고려하지 않은 채 고급 기술을 초보 개발자에게 이용하게 해서 장해를 일으키거나, 부적절한 기술 은닉으로 기술 이용을 어렵게 하는 문제도 개발 현장에서는 흔히 볼 수 있다. 게다가 고객 클래스나 수주 클래스 내에 고객이나 수주 처리라고 하기 어려운 트랜잭션이나 예외, 로깅과 같은 처리가 들어가면 프로그램의 가독성을 현저하게 떨어뜨릴 우려가 있다. 또한 여러 클래스에 걸쳐 존재하는 트랜잭션이나 예외 처리, 로깅 처리는 프로그램의 가독성을 떨어뜨리기도 하고, 유닛 테스트 역시 어렵게 만들기도 한다. 덧붙여 여러 클래스에 걸쳐 있는 트랜잭션의 예외 처리 및 로깅 처리는 부품화를 촉진하는 데 방해가 되기도 한다.

웹 애플리케이션을 구축하는 오브젝트 사이의 의존 관계는 인터페이스를 매개로 해서 구현에 의존하지 않음으로써 오브젝트 사이를 약한 결합으로 유지할 수 있다. 또한, 그렇게 함으로써 오브젝트를 쉽게 확장-변경하고, 개발 효율을 올리며, 시스템을 고품질로 유지할 수 있음은 앞에서 설명했다. 예를 들어 오브젝트가 인터페이스에만 의존하면 인터페이스가 확장/변경되더라도 이용하는 오브젝트에는 아무 영향도 주지 않는다. 또한, 인터페이스의 배후에 있는 오브젝트가 미완성일 때에도 mock 오브젝트로 치환해 개발을 중단하지 않고 진행할 수 있으며, 테스트용 클래스로 치환해 손쉽게 테스트를 시행할 수 있다. 이러한 사고방식을 적극적으로 밀고 나가면 전자 제품처럼 부품별로 개발 거점을 나누어 작성할 수 있다. ※ 물론 Moc..

EJB의 문제(현재는 문제점이 해결된 상태) 이전에 스프링은 안티 EJB라는 느낌이었지만, EJB 자체가 버전 3.0으로 넘어가면서 DI 컨테이너, AOP 프레임워크가 됐으므로 이제 EJBㅣ와 비교해 스프링의 우위를 증명하는 방법은 성립하지 않는다. 과거에 EJB라는 중량 컨테이너의 안티테제(antithese)로서 경량 컨테이너를 자처하고 등장한 스프링이 현재는 오히려 비교 대상이 Java EE가 됐을 정도로 스프링은 거대해졌다. 이를 방지하려면 서비스 로직의 오브젝트는 싱글턴(singletone)으로 해야 하지만, 오브젝트를 싱글턴으로 하려면 구현을 변경해야 하고, 어떤 사정으로 오브젝트가 싱글턴일 필요가 없어졌을 때의 비용이 커지는 단점이 있다. 또한, 마찬가지로 싱글턴처럼 오브젝트가 HTTP의 Se..

지금까지 개발 효율성과 유연성 향상을 애플리케이션 설계 목표로 삼고 이를 실현하는 방법으로 티어와 레이어에 관해 이야기했다. 정리하면 결국 애플리케이션을 부품화하자는 말로 통일된다. 부품이 큰 쪽은 티어나 레이어가 되고, 그보다 작은 부품은 패키지나 컴포넌트가된다. 그리고 부품끼리는 인터페이스로 연결된다. 정리하면 이 모든 것이 부품화라고 할 수 있다. 더 간단히 말하자면, TV, DVD 레코더, 스피커 등으로 구성된 가전제품이나 모니터, 마우스, 메인보드, CPU와 메모리 등으로 구성된 컴퓨터처럼 애플리케이션을 여러 부품으로 조립된 전자 제품과 같은 아키텍처로 만들어서 개발 효율성과 유연성을 높이는 것이다. 티어나 레이어처럼 큰 부품은 현실 세계에서 컴퓨터와 모니터, 스피커에 해당한다고 생각하면, 패키..

DB 액세스 프레임워크로 흔히 알려진 것은 ORM(O/R 매핑 프레임워크)이다. ORM은 XML 드응로 기술된 매핑 파일로, 오브젝트와 테이블을 매핑한다. 매핑 파일 작성은 손이 많이 가지만 개발자가 SQL 문을 작성하지 않아도 된다는 특징이 있다. ORM의 대표적인 프레임워크가 하이버네이트이다. 반면 직접 SQL문 사용을 전제로 한 DB 액세스 프레임워크도 있다. 스프링에 포함된 스프링 JDBC나 MyBatis가 여기에 해당한다. 데이터 액세스 층의 설계 지침 설계를 생각하기 전에 데이터 액세스 층의 구현을 생각해보자. 데이터 액세스 층의 구현은 O/R 매핑인지 R/O 매핑인지에 따라 달라진다. O/R 매핑은 ORM이라고 일컫는 하이버네이트 등을 이용한다. R/O 매핑으로도 테이블 구조가 복잡하면 스프..

데이터 액세스 층의 역할 데이터 엑세스 층은 기본적으로 RDB(테이블) 엑세스를 비즈니스 로직에서 숨기고, 비즈니스 로직에 필요한 데이터를 테이블에 취득해서 오브젝트에 매핑하는 것이다. 이렇게 오브젝트와 RDB를 매핑하는 것을 O/R매핑이라고 한다. [O는 Object, R은 Relational(테이블)] O/R매핑 O/R매핑은 시스템 개발 방법에 따라서 O에서 R과, R에서 O의 두 가지 방향이 존재한다. 일반적으로 O에서 R의 O/R 매핑은 객체 지향 분석으로 엔티티(도메인 모델의 클래스)를 추출해, 그 엔티티를 바탕으로 설계 단계에서 테이블을 작성한다. 기본적으로 테이블읠 한 레코드가 한 오브젝트에 대응한다. 객체 지향으로 분석-설계하면 일반적으로 이러한 O/R매핑이 된다. 마찬가지로 R에서 O의 ..

트랜잭션이란 간단히 말해 처리 단위이다. 예를 들면, 웹 사이트에서 검색하고 상품 목록을 보기까지의 트랜잭션, 웹 사이트에서 상품을 주문해서 상품이 집에 도착하기까지처럼 긴 트랜잭션, 주문을 받고 발주 테이블과 고객테이블, 재고 테이블을 갱신하는 데이터베이스 트랜잭션 등이 있따. 여기서는 그중 데이터베이스 트랜잭션을 다루지만, 이처럼 다양한 트랜잭션이 있다는 점을 기억해야 한다. 이 트랜잭션에는 지켜야 할 ACID라는 특성이 있다. 이 중에서 애플리케이션 아키텍처로서 신경을 써야하는 것은 원자성(atomicty), 독립성(isolation)이다. 반면, 영속성(durability)은 우리가 만드는 애플리케이션의 전제 조건이라고 할 수 있다.(애플리케이션에서 어떻게 영속성을 보증할 것인가?) 시스템을 구축..

대규모 개발쯤 되면 기본적으로 트랜잭션 스크립트와 같은 로직 주도 설계로 만드는 경우가 많지만, 최근 시스템 개발은 비즈니스 로직이 복잡한 것도 많다. 또한 웹 애플리케이션의 생명 주기를 고려해 상속 등 객체 지향의 이점을 살린 변경이나 확장의 용이성이 필요할 때도 많다. 그럴 때 트랜잭션 스크립트 비즈니스 로직이 된다. 이를 방지하려면 도메인 패키지의 클래스에 도메인 로직을 두는 도메인 모델로 비즈니스 로직 층을 만드는 것이 좋다. 다만 실제 개발에서는 도메인 모델을 이용해 아름답게 만드는데 너무 집착하다가 동작하지도 않고 납품할 수도 없는 애플리케이션을 만드는 일만은 피하자. 현실에서는 도메인 모델로 만들다 한계를 느끼면 재빨리 트랜잭션 스크립트로 전환하는 두뇌의 유연성도 필요하다. 그리고 앞으로를 ..

비즈니스 로직 층을 설계할 때는 어느 클래스에 로직을 할당할지 중요하다. 판단하기 아주 어려운 문제지만 설계 실력을 보여줄 수 있는 기회이기도 하다. 여기서 실패하면 아픙로의 작업이 힘들어지므로 실제 개발에서는 서둘지 말고 차분히 생각해서 결정해야 한다. 트랜잭션 스크립트 일반적인 지침으로는 데이터베이스의 내용을 표시/변경하기만 하는 업무 처리, 즉 비즈니스 로직이 적은 단순 입출력 애플리케이션일 때는 로직을 전부 서비스 클래스에 포함시키는 편이 좋다. 또한, 객체 지향 지식이 없는 프로그래머가 많이 일하는 대규모 개발 프로젝트에서도 도메인에는 가능한 한 로직을 포함시키지 않는 편이 좋을 것이다. 이때는 도메인이 아니라 단순히 값을 저장하기만 하는 오브젝트, 사람에 따라서는 VO{(Value Object..