[Web] Layered Architecture
Layered Architecture?
웹 페이지는 중복 개발되는 요소가 존재한다.
Controller에서 중복되는 부분을 처리할 때는 별도의 객체/메소드 로 분리하는 방법을 사용한다.
컨트롤러와 서비스
비즈니스 메소드를 별도의 Service 객체에서 구현하도록 하고 컨트롤러는 Service 객체를 사용하도록 하면 효율적이다.
서비스 객체
비즈니스 로직을 수행하는 메소드를 가지고 있는 객체. 보통 하나의 비즈니스 로직은 하나의 트랜잭션으로 동작한다.
트랜잭션 : 하나의 논리적인 작업 단위.
- 특징
1. 원자성 - Atomicity : 전체가 성공하거나, 전체가 실패 하도록 하는 것
2. 일관성 - Consistency : 트랜잭션 작업 처리 결과가 항상 일관성이 있어야함
3. 독립성 - Isolation : 어느 하나의 트랜잭션이라도 다른 트랜잭션의 연산을 끼어들 수 없음
4. 지속성 - Durability : 트랜잭션이 성공적으로 끝났을 때 그 결과가 영구적으로 반영됨
JDBC
JDBC 프로그래밍에서는 DB에 연결된 후 Connection객체의 setAutoCommit 메소드가 디폴트 값으로 true를 가지고 있어 자동으로 commit이 된다. 트랜잭션을 구현하고 싶다면, 해당 메소드에 false를 파라미터로 지정하고, 작업을 수행한 후 commit()메소드를 호출한데까지 트랜잭션이 된다.
Spring
@EnableTransactionManagement
Spring Java Config파일에서 트랜잭션을 활성화할때 사용하는 어노테이션이다. java config를 사용하게 되면 PlatformTransactionManager 구현체를 모두 찾아서 그 중 하나를 매핑해 사용한다. 특정 트랜잭션 매니저를 사용하고 싶다면 TransactionManagementConfigurer를 java config 파일에서 구현하고 원하는 트랜잭션 매니저를 리턴하도록 하면 된다. 또는 특정 트랜젝션 매니저 객체를 생성하고 @Primary 어노테이션을 지정할 수도 있다.
서비스 객체에서도 중복으로 호출되는 코드가 있을 수 있는데, 데이터 액세스 메소드를 별도의 Repository(DAO) 객체에서 구현하도록 하고 서비스는 Repository 객체를 사용하도록 한다.
Presentation Layer는 얼마든지 다른 플랫폼으로 바뀔 수 있다. 따라서 Service Layer와 Repository Layer 의 설정은 따로 관리 하는 것이 이후 재사용성을 높히고 관리하기도 쉽다.
web.xml 파일에서 프리젠테이션 레이어에 대한 스프링 설정은 DispatcherServlet이 읽도록 하고 그 외 설정은 ContextLoaderListener를 통해서 읽도록 한다. DispatcherServlet을 경우에 따라 2개 이상 설정할 수 있는데 이 경우 각각의 디스패쳐 서블릿의 ApplicationContext가 각각 독립적이기 때문에 각각의 설정 파일에서 설정한 빈은 서로 사용할 수 없다. 이런 경우 동시에 필요한 빈은 ContextLoaderListener를 사용하면 공동으로 사용할 수는 있지만 권장되지 않는다.
ContextLoaderListener와 DispatcherServlet은 각각 ApplicationContext를 생성하는데 ContextLoaderListener가 생성하는 ApplicationContext가 root 컨텐스트가 되고 DispatcherServlet이 생성하는 인스턴스는 root 컨텍스트를 부모로 하는 자식 컨텍스트가 된다. 자식 컨텐스트들은 root 의 설정 빈을 사용할 수 있다.
레이어 구조로 프로젝트를 구현하는 것의 장점은 레이어 구조를 사용하지 않을 경우 단점을 생각해보면 된다. 1. 중복된 코드가 많아지고 스파게티 코드가 되어 코드의 가독성이 나빠질 확률이 높고, 2. 모든 처리를 presentation에서 하게 되는데 이 경우 Model을 다루는 건지 Controller를 다루는 건지 모호해지는 경우가 생길 수 있다.
웹 페이지는 중복 개발되는 요소가 존재한다.
Controller에서 중복되는 부분을 처리할 때는 별도의 객체/메소드 로 분리하는 방법을 사용한다.
컨트롤러와 서비스
비즈니스 메소드를 별도의 Service 객체에서 구현하도록 하고 컨트롤러는 Service 객체를 사용하도록 하면 효율적이다.
서비스 객체
비즈니스 로직을 수행하는 메소드를 가지고 있는 객체. 보통 하나의 비즈니스 로직은 하나의 트랜잭션으로 동작한다.
트랜잭션 : 하나의 논리적인 작업 단위.
- 특징
1. 원자성 - Atomicity : 전체가 성공하거나, 전체가 실패 하도록 하는 것
2. 일관성 - Consistency : 트랜잭션 작업 처리 결과가 항상 일관성이 있어야함
3. 독립성 - Isolation : 어느 하나의 트랜잭션이라도 다른 트랜잭션의 연산을 끼어들 수 없음
4. 지속성 - Durability : 트랜잭션이 성공적으로 끝났을 때 그 결과가 영구적으로 반영됨
JDBC
JDBC 프로그래밍에서는 DB에 연결된 후 Connection객체의 setAutoCommit 메소드가 디폴트 값으로 true를 가지고 있어 자동으로 commit이 된다. 트랜잭션을 구현하고 싶다면, 해당 메소드에 false를 파라미터로 지정하고, 작업을 수행한 후 commit()메소드를 호출한데까지 트랜잭션이 된다.
Spring
@EnableTransactionManagement
Spring Java Config파일에서 트랜잭션을 활성화할때 사용하는 어노테이션이다. java config를 사용하게 되면 PlatformTransactionManager 구현체를 모두 찾아서 그 중 하나를 매핑해 사용한다. 특정 트랜잭션 매니저를 사용하고 싶다면 TransactionManagementConfigurer를 java config 파일에서 구현하고 원하는 트랜잭션 매니저를 리턴하도록 하면 된다. 또는 특정 트랜젝션 매니저 객체를 생성하고 @Primary 어노테이션을 지정할 수도 있다.
서비스 객체에서도 중복으로 호출되는 코드가 있을 수 있는데, 데이터 액세스 메소드를 별도의 Repository(DAO) 객체에서 구현하도록 하고 서비스는 Repository 객체를 사용하도록 한다.
Presentation Layer는 얼마든지 다른 플랫폼으로 바뀔 수 있다. 따라서 Service Layer와 Repository Layer 의 설정은 따로 관리 하는 것이 이후 재사용성을 높히고 관리하기도 쉽다.
web.xml 파일에서 프리젠테이션 레이어에 대한 스프링 설정은 DispatcherServlet이 읽도록 하고 그 외 설정은 ContextLoaderListener를 통해서 읽도록 한다. DispatcherServlet을 경우에 따라 2개 이상 설정할 수 있는데 이 경우 각각의 디스패쳐 서블릿의 ApplicationContext가 각각 독립적이기 때문에 각각의 설정 파일에서 설정한 빈은 서로 사용할 수 없다. 이런 경우 동시에 필요한 빈은 ContextLoaderListener를 사용하면 공동으로 사용할 수는 있지만 권장되지 않는다.
ContextLoaderListener와 DispatcherServlet은 각각 ApplicationContext를 생성하는데 ContextLoaderListener가 생성하는 ApplicationContext가 root 컨텐스트가 되고 DispatcherServlet이 생성하는 인스턴스는 root 컨텍스트를 부모로 하는 자식 컨텍스트가 된다. 자식 컨텐스트들은 root 의 설정 빈을 사용할 수 있다.
레이어 구조로 프로젝트를 구현하는 것의 장점은 레이어 구조를 사용하지 않을 경우 단점을 생각해보면 된다. 1. 중복된 코드가 많아지고 스파게티 코드가 되어 코드의 가독성이 나빠질 확률이 높고, 2. 모든 처리를 presentation에서 하게 되는데 이 경우 Model을 다루는 건지 Controller를 다루는 건지 모호해지는 경우가 생길 수 있다.
No comments: