횡단 관심은 로깅, 보안 미 트랜잭션 관리 등과 같은 애플리케이션의 여러 레이어에 대한 일반적인 공통 관심사다.
- 로깅 : 관점 지향 프로그래밍 (AOP, AspectJ)을 사용해 여러 레이어에서 로깅을 구현 할 수 있다.
- 보안 : 본안은 일반적으로 스프링 시큐리티 프레임워크를 사용해 구현한다.
- 트랜잭션 관리 : 스프링 프레임워크는 트랜잭션 관리를 위한 일관된 추상화를 제공한다. 더 중요한 것은 스프링 프레임워크가 선언적 트랜잭션을 관리할 수 있도록 지원한다는 것이다. 스프링 프레임워크가 지원하는 트랜잭션 API 중 일부
- 자바 트랜잭션 JTA는 트랜잭션 관리의 표준이다.
- JDBC, JPA
- 에러 처리 : 스프링에서 제공하는 대부분의 추상화된 언체크된 예외를 사용하므로 비즈니스 로직에서 요구하지 않는 한 클라이언트에 노출된 레리어에서 에러 처리를 구현하는 것으로 충분하다. 스프링 MVC는 애플리케이션 전반에 걸쳐 일관된 에러 처리를 구현하는 컨트롤러 어드버이스를 제공한다.
- 느슨한 결합 및 테스트 가능성
- 복잡한 코드
- 경량 아키텍처
- 아키텍처의 유연성
- 횡돤 관심의 간소화된 구현
- 최상의 디자인 패턴
스프링은 의존성 주입을 통해 클래스 간의 느슨한 결합을 제공한다. 느슨한 결합의 장점은 장기적으로 애플리케이션 유지보수에 도움이 크며, 테스트가 가능하게 하며 보다 좋은 테스트 코드를 만들 수 있다. 과거 EJB2 같은 경우에는 테스트하는 유일한 방법은 컨테이너에서 실행해보는 것밖에 안됬다. 그래서 단위 테스트에 어려움이 있었다. 하지만 스프링은 모킹 의존성을 이용해서 객체에 쉽게 연결할 수 있어 테스트하기 편하다.
과거 개발자는 JDBC를 통해 간단한 쿼리를 실행하고 결과를 자바 객체로 채우기 위해 작성해야 하는 복잡한 코드들에 익숙해져있다. 자바 네이밍 및 디텍터 인터페이스(JNDI) 검색을 수행하고 연결을 설정한후, 결과를 채워야 했기 때문에 코드가 중복됐다. 일반적으로 모든 메서드에서 예외 처리 코드로 문제가 반복됐다. 이 문제는 JDBC에만 국한되지 않는다. 스프링이 해결한 이러한 문제중 하나는 모든 복잡한 코드를 제거하는 것이다. 개발자는 JDBC, 스프링 JMS 및 기타 추상화를 통해 비즈니스 로직의 작성에만 집중할 수 있다.
스프링은 여러 레이어의 애플리케이션에서 객체를 연결하는 데 사용된다, 스프링은 애플리케이션 아키텍처와 개발자의 프레임워크 선택 및 유연성을 제한하지 않는다.
스프링 프레임워크는 웹 레이어에 큰 유연성을 제공한다. 스프링 MVC 대신 스트럿츠나 스트럿츠2를 사용하고자 한다면 설정이 가능 하다. 더 넓은 범위의 뷰 및 템플릿 프레임워크와 통합할 수 있는 선택권이 있다. 예를 들어 뷰 템플릿을 추가하거나 변경하려면 View Resolver를 변경하거나 추가하면된다. 이 또한 추상화가 잘돼있어 일관된 코딩 방식을 보장 받을 수 있다.
스프링 프레임워크를 사용해 빈을 관리할 때, 스프링 IoC 컨테이너는 빈의 생성, 사용 오토와이어링 및 파기 등과 같은 생명주기를 관리한다. 빈을 중심으로 횡단 관심과 같은 추가 기능을 더 쉽게 만들 수 있다.
스프링은 기본적으로 많은 디자인 패턴의 사용을 권장한다.
- 의존성 주입, IoC : 스프링 프레임워크가 구현할 수 있도록 설계된 기본적 설계 패턴이다. 느슨한 결합 및 테스트가 가능하다.
- 싱글톤 : 모든 스프링 빈은 기본적으로 싱글톤이다.
- 팩토리 패턴 : 빈 팩토리를 사용해 빈을 인스턴스화하는 것은 팩토리 패턴의 좋은 예이다.
- 프론트 컨트롤러 : MVC DispatcherServlet을 프런터 컨트롤러로 사용한다. 이로써 스프링 시큐리티와 같은 ACL 작업들을 보다 효율적으로 진행할 수 있다.
- 템플릿 메서드 : 사용구 코드를 피할 수있다. 스프링 기반의 클래스인 JdbcTemplate 대표적인 예이다.