Spring과 웹 애플리케이션

산뜻하네

스프링은 대규모 애플리케이션을 자바로 만들때 필요한 프레임워크이며,

구현을 위한 프레임 워크가 아닌 설계를 위한 프레임워크이다. 

 

스프링 이론을 공부하면서 부족하고 헷갈린것들을 정리 해보려한다. 히ㅏ호하하ㅏ

---

• 스프링 동작 규정을 정의 해 놓은 파일

- Bean: 특정한 일을 독립적으로 수행하는 컴포넌트이다.

- 자바빈: JSP에서 사용되는 데이터를 저장 및 관리하기 위한 컴포넌트이다.

- Annotation: 자바 코드에 주석을 달아 특별한 의미를 부여한다. 이 의미는 컴파일 타임 또는 런타임으로 해석된다.

 

여기서 어노테이션은 클래스와 메서드에 추가해서 다양한 기능을 부여하는 역할이다. 코드량을 줄일 수 있고 유지보수하기 쉬워진다. @~ 방식으로 사용된다.

@Test
    void 예외_테스트() {
        assertSimpleTest(() ->
                assertThatThrownBy(() -> runException("1234"))
                        .isInstanceOf(IllegalArgumentException.class)
        );
    }

 

 

다양하게 있으나 그 중 최근에 사용한건 @Test 였다. JUnit에서 테스트 할 대상을 표시한다.

 

*컴포넌트 : 여러 개의 프로그램 함수를 모아서 특정한 기능을 수행하게 구성한 작은 기능적 단위이다. 독립적인 단위 모듈이다.

 

• 웹 애플리케이션의 구조

 

사용자가 웹 브라우저를 통해 DB에 접근하고 안전하게 정보를 읽고 쓰게해주는 애플리케이션이다.

화면을 통해 사용자가 동작하면 동작에 대한 비즈니스 로직을 RDB데이터를 사용해 처리하고, 이를 화면에 다시 전송하여 결과를 사용자에게 보내주는 구조이다.

 

웹 애플리케이션 발전사

 

HTML ->  (정적 콘텐츠) 

CGI(동적 콘텐츠) -> 세션 관리가 없고 1요청 1프로세스 

서블릿, JSP  -> 세션관리와 멀티 쓰레드 사용 JSP로 페이지 생성, 비즈니스 로직을 서블릿으로 처리

EJB  -> 분산 오브젝트, 원격 액세스 지원으로 쇠퇴

스프링  -> 단위 테스트가 어렵다. 불필요한 메서드를 구현해야 한다. 예외 처리가 번거롭다. 배포가 불편하다.

를 개선하려고 나온 프레임 워크. DIxAOP 컨테이너

---

DI- 의존성 주입. 프레임워크에 의해서 의존성이 주입되는 설계 패턴

AOP- 관점지향 프로그래밍 :공통되는 작업들을 모아서 필요한 시기에 적용하는 개념

---

• 레이어의 3계층

레어어의 3계층

 프리젠테이션 층  사용자 인터페이스  UI와 컨트롤러를 제공한다.

 

UI : 사용자가 직접 조작하는 화면이나 장표, 화면 인터페이스

컨트롤러 : 사용자 인터페이스를 통해 사용자 입력을 받아 적절한 비즈니스 로직을 호출하고, 그 결과를 사용자
인터페이스로 반환하는 작업

웹 애플리케이션의 상태(세션)을 저장해 이용하는 데이터를 관리한다.

mvc2

모델(Model): 빈

컨트롤러(Cotroller) : 서블릿

뷰(View): JSP

프리젠테이션과 비즈니스 로직을 분리하여 변경을 최소화하는 방향으로 발전했다.

 비즈니스 로직 층 - 서비스와 도메인같은 비즈니스 로직을 구현한다.

 

핵심 업무 로직의 처리 방법 기술과 관련 데이터의 적합성을 검증한다.

프레젠테이션 계층과 데이터 액세스 계층 사이 연결하는 역할을 한다.

트랜잭션 관리를 한다.

 

 

서비스 -  특정 업무나 특 정 부서 처리의 통합. 트랜젝션의 기점. 일반적으로는 자신의 상태  를 나타내는 값을 가지지 않는 클래스.

도메인 : 서비스로부터 비즈니스를 실행하는데 반드시 사용하는 클래스의 집합. 자신이 무엇인지 나타내는 값과 그 값을 이용한 처리를 실현한다.

 

트랜잭션 : 일 처리단위 4가지 ACID특성이 존재

ACID	의미	설명
Atomicity	트랜잭션의 원자성	트랙잭션 내의 모든 처리는 전부 실행되거나 아무것도 실행되지 않았어야 한다.
Consistency	데이터의 일관성	데이터에 일관성이 있어야한다.
Isolation	트랜잭션의 독립성	병행해서 실행하는 트랜잭션이 서로 독립이어야 한다.
Durability	데이터의 영속성	데이터가 영속화 되어야하며 읽어서 출력 할 수 있어야 한다.

* 영속성? : 데이터의 영속성(persistence)이란 “프로그램이 종료되더라도 사라지지 않는 데이터의 성질"을 의미한다.

 

시스템 구축시 원자성 범위를 정해야한다. -> 어디서 시작할 지

때문에 경계선을 긋는데 이를 트랜잭션 경계선이라고 한다. 관리해야할 트랜잭션 대상의 메소드가 여러 층으로 흩어진다면 관리가 어려워지므로 일정한 규칙으로 시작과 종료가 이뤄지는 메소드를 정리해야한다.

 

• 선언적 트랜잭션 방법

서비스 클래스의 메소드에 경계를 지어 프레임워크에서 제공하는 기능으로 관리한다.

아키텍처를 유연하게 설계할 수 있다.

 

선언적 트랜잭션

• 명시적 트랜잭션

프리젠테이션 층의 컨트롤러로 트랜잭션을 구현한다. 비즈니스 층에 포함된 컴포넌트들은 트랜잭션으로 부터 자유롭게 해야한다.

명시적 트랜잭션

 

 데이터 액세스 층 - DB 액세스를 추상화

 

RDB(테이블) 액세스를 비즈니스 로직에 숨기고, 필요한 데이터를 테이블에서 가져와 오브젝트에 매핑한다.

O/R 매핑 : object와 RDB를 매핑하는것.

---

• 웹 애플리케이션의 레이어

- 오목형 레이어

오목형 레이어

 

오목형 레이어가 왜 좋은 설계냐면 두가지 안전 의존 원칙과 의존 관계 역전 원칙을 기반으로 한 설계기 때문이다

프레젠테이션 층과 데이터 액세스 층이 변동이 있어도 비즈니스 로직층에는 영향이 없다.

ex) 웹 > 안드로이드, RDB -> noSql 바뀌어도 비즈니스 로직층은 그대로 사용 가능.

 

안전 의존 원칙 : 다른 패키지가 변경 되었을 때 영향을받지 않는 것.

의존 관계 역전 원칙 : 다른 패키지에 가장 큰 영향을 줄것 같은 위치에 있는 패키지의 의존 방향성을 바꾸기 위한
원칙. 의존 관계가 뒤바뀌면 인터페이스의 소유권도 바뀌므로 주의.

1. 상위 모듈은 하위 모듈에 의존해서는 안 되고 둘 다 추상화에 의존해야 한다.
2. 추상화는 세부 사항에 의존해서는 안 되고 세부사항(구체적인 구현)은 추상화에 의존해야 한다.

 

---

• 웹 애플리케이션 개발의 3가지 문제점

 

1. 오브젝트의 생명주기 문제
2. 부품화 문제
3. 기술 은닉과 부적절한 기술 은닉 문제

 

• 오브젝트의 생명주기 문제

웹 애플리케이션은 사용자 요구에 유연하게 대처하는 아키텍처가 필요하다.

시대에 따라서 필요한 기능이 증가되거나 필요 없어지는데 이를 수정하기 위해서 유연성이 필요하다

 

• 부품화

오브젝트 사이의 의존관계→ 인터페이스를 매개로 구현해서 오브젝트 사이를 약한 결합으로 유지함.

오브젝트를 쉽게 확장 및 변경이 가능하고 개발 효율이 올라간다.

또한 오브젝트가 인터페이스에만 의존할 시 인터페이스가 확장 변경되어도 오브젝트에는 영향이 없다.

인터페이스 배추에 있는 오브젝트가 미완성이면 "mock"오브젝트로 치환하거나 테스트용 클래스로 치환해 진행한다.

 

*mock? : 실제 객체를 다양한 조건으로 인해 제대로 구현하기 어려울 경우 가짜 객체를 만들어 사용한다.

부품별 개발

 

• 기술 은닉의 문제

기술을 은닉하지 않으면 제어를 초보자에게 맡겼다 통합 테스트에서 오류가 빈발하는 경우도 생겼다.

기술을 은닉한경우 이용 절차가 복잡해서 사용자들에게 외면 받는 경우가 생겼다.

 

이러한 문제들은 스프링으로 해결하자.

 오브젝트의 생명주기 문제 – DI 컨테이너로 해결
 부품화 문제 – DI 컨테이너로 해결
 기술 은닉과 부적절한 기술 은닉 문제 - AOP로 해결