7 Week

4 분 소요




JDBC

JDBC의 정의

데이터베이스 접근기술


JDBC Driver

서로 다른 디비들에 대한 연결방법이 모두 다르기 때문에 거기에 대응하기 위해서 사용한다.
결국 디비가 서로 다르고 다른 연결방식 이어도 모두 같은방식으로 다루고 싶고
또한 프로그래밍 단에서는 하나의 방식으로 사용하고 싶기 때문에 사용한다.


JDBC API

드라이버가 매꿔준 걸 이용해서 같은방식으로 디비에 대한 접근을 제공하는 인터페이스
API는 Application Programming Interface의 약자이고
JDBC API란 여기에 접근하기 위해 추상적으로 공개한 루트이다.
이것도 결국 프로그래밍 단에서 다른걸 신경쓰지 않고 하나의 방법으로 사용하고 싶기 때문


Connection Pool

데이터베이스에 대한 커넥션을 미리 생성해두고 재사용 하기 위한 방법
어플리케이션 시작 시점에 필요한 만큼의 커넥션을 미리 확보해서 풀에 보관한다.


왜쓰는데?

DB Driver는 데이터베이스와 TCP/IP 커넥션을 연결하는데, 이 과정에서 3 way handshake 같은
네트워크 동작이 발생하게 된다.
3 way handshake 는 Network Pass 를 확보하는데 3번의 통신을 해야 서로가 신뢰를
가지고 Pass 를 확정하기 때문에 이 과정에서 시간이라는 리소스가 많이 들어가게 된다.
비용적인 측면에서 느린거로는 네트워크가 압도적이기 때문에 Connection Pool 을 사용한다.





To Do





MVC

어플리케이션을 Model-View-Controller 의 세가지 컴포넌트로
각각 담당하는 역할을 구분한 디자인패턴

  1. 사용자가 입력을 담당하는 View 를 통해 요청을 보낸다.
  2. 해당 요청을 Controller 가 받고 Model 을 통해 데이터를 가져온다.
  3. 해당 데이터를 바탕으로 출력을 담당하는 View 를 통해 사용자에게 전달한다.
    MVC패턴은 모델1과 모델2가 있다.
  • 모델 1
    • JSP에서 출력과 로직을 전부 담당
    • 사용자 요청을 JSP가 JavaBean Service Class 를 사용해 전부 처리
    • 빠르고 쉽게 개발할 수 있지만 유지보수맟 확장에 어려움
  • 모델 2
    • JSP에서 출력만 담당
    • 사용자 요청을 서블릿이 받음
    • 설계가 어렵지만 분업이 가능하며 유지보수 및 확장에 용이


Model

  • 어플리케이션의 정보, 데이터 등을 담당하고 정보들의 가공을 책임지는 컴포넌트
  • 비즈니스 로직 처리
  • 편집하기 원하는 모든 데이터를 가지고 있어야 한다.
  • 변경이 일어나면, 변경통지에 대해 처리방법을 구현해야 한다.
  • View / Controller 에 대해 의존하지 말아야 한다.


View

  • 데이터의 입력과 보여지는 출력을 담당
  • Model 의 정보를 가지고 있지 말아야 한다.
  • 변경이 일어나면, 변경통지에 대해 처리방법을 구현해야 한다.
  • Model / Controller 에 의존하지 말아야 한다.


Controller

  • Model / View 의 중간다리 역할을 한다.
  • 요청에 대해 해당 요청을 담당하는 Model 을 호출한다.
  • Model 의 작업결과를 리턴받아 View 에게 전달한다.
    • Model / View 에 대해 알고있어야 한다.


Web에 적용할 시

  1. 유저가 웹사이트에 접속
  2. Controller 는 접속요청에 대해 Model 호출
  3. Model 은 디비나 파일같은 데이터를 비즈니스 로직을 통해 처리 후 리턴
  4. Controller 는 리턴받은 결과를 View 에 전달
  5. 리턴받은 결과는 View 를 통해 유저에게 보여짐


왜쓰는데?

사용자 UI / 비즈니스 로직 / 중간다리 이렇게 3가지로 구분하여 어플리케이션을
설계하면 각각 자신의 역할에만 집중할 수 있다.
이로인해 유지보수, 확장성, 유연성이 증가하고 중복을 줄일 수 있다.


단점

설계에 리소스가 들어간다. 예를들어

  • Model / View 가 다른 컴포넌트 들에게 독립적이게 설계하는 것
  • Model 의 설계를 잘해야 변경에 유연할 수 있는것

제대로 설계를 하지 않으면 View 와 Model 의 분리가 어려운데
Controller 를 통해 하나의 View에 연결될 수 있는 Model 도 여러 개가 될 수 있어
View 와 Model 이 서로 의존성을 띄게 될 수 있다.
즉, Controller 하나에 다수의 Model / View 가 복잡하게 얽히는 상황이 일어날 수 있다.





MVP

Model-View 는 MVC 패턴과 동일하고 Controller 대신 Presenter 가 존재하는 패턴
MVC 패턴 과 다른 핵심적인 설계는 View 와 Model 을 완전히 분리하고 서로간의 상호작용을
Presenter 에게 위임하여 서로의 의존성을 최소화 하는데 있다.

  • Presenter
    • View 와 Model 의 인스턴스 를 가지고 있다.
    • Presenter 와 View 는 1:1 관계이다.
    • View 에 직접 연결되는게 아니라 인터페이스를 통해 상호작용 한다.


동작

  1. 사용자 요청은 View 를 통해 들어옴
  2. View 는 데이터를 Presenter 에 요청
  3. Presenter 는 Model 에게 데이터 요청
  4. Model 은 Presenter 에게 요청받은 데이터 응답
  5. Presenter 는 View 에게 데이터를 응답
  6. View 는 Presenter 가 응답한 데이터를 사용해 화면을 나타냄


왜쓰는데?

Presenter 를 통해서만 데이터를 전달 받기 때문에 View-Model 간의 의존성이 없다.
View-Model 을 분리시켜 View 와 비즈니스 로직이 완전히 분리되어 MVC 패턴에서
하기 힘든 테스트가 쉬워졌다.
View-Model 간의 의존성은 해결되었지만 반대로 Presenter 를 통해서만 Data를 전달받기 때문에
View-Presenter 간의 의존성이 높아지고 Controller 대신 Presenter 가 복잡해 진다.





MVVM

Command 패턴과 Data Binding 이라는 두 가지 패턴을 사용하여 구현되었다.
Command 패턴과 Data Binding을 이용하여 View 와 View Model 사이의 의존성을 없앰
Model-View 는 MVC 패턴과 동일하고 Controller 대신 View Model 이 존재한다.

  • View Model
    • View 를 표현하기 위해 만든 View 를 위한 Model 이다.
    • View 에서 필요로 하는 데이터 처리와 비즈니스 로직을 수행한다.
    • View Model 과 View 의 관계는 1:N 관계이다.


  • Data Binding?
    • Model 과 UI 요소간의 싱크를 맞추는 것
    • 이 패턴을 통해 View 와 로직이 분리되어 있어도 한쪽이 바뀌면 다른쪽도
      업데이트가 이루어져 데이터의 일관성을 유지할 수 있음


동작

  1. 사용자 요청은 View 를 통해 들어옴
  2. View 는 Command 패턴으로 View Model 에게 요청 전달
  3. View Model 은 Model 에게 데이터 요청
  4. Model 은 View Model 에게 요청받은 데이터 응답
  5. View Model 은 응답받은 데이터를 가공하여 저장
  6. View 는 View Model 과 Data Binding 하여 화면을 나타냄


왜쓰는데?

View-Model 간의 의존성이 없다.
Command 패턴과 Data Binding을 사용하여 View-View Model 간의 의존성 또한 없앤 디자인패턴
각각의 부분은 독립적이기 때문에 모듈화 하여 개발할 수 있는 장점이 있다.
하지만 View Model 의 설계가 쉽지 않고 Data Binding 이 필수로 요구되는 단점이 있다.
또한 어플리케이션이 복잡해 질수록 View Model 이 거대해진다.





정리

이 패턴들의 공통적인 특징이자 장점은 처리결과를 화면에 보여주는 로직과 실제 데이터가
처리되는 로직을 분리 하는 것이다. 정답은 없고 상황에 맞게 적절히 응용하여 사용하는것이 중요하다.
구조의 단위가 화면인지 컴포넌트인지에 따라 선택하는 것도 좋은 방법이다.


MVC

  • Model 과 View 로직이 상호간에 의존적이다.
  • Controller 에 의해 특정 Model 에 따라 데이터가 처리되면 사전에 정의된 View 를 반환해 준다.


MVP

  • 사용자 입력을 View 에서 직접 받고 Presenter 와 상호작용 하는 차이가 있다.
  • View 는 Presenter 와만 통신하므로 Model 에 대해 알 필요가 없다.
    • 결과적으로 Model-View 간의 의존성이 사라진다.
  • View 와 Presenter 간의 강한 1:1 의존관계가 있다는 단점이 존재한다.


MVVM

  • View 를 표현하기 위해 만들어진 View 만을 위한 Model 인 View Model 을 사용한다.
  • View 로 전달된 입력에 의해 Command 패턴에 따라 View Model 에 명령을 내리고,
    데이터가 변화하면 그것에 따라 Data Binding 된다.
    • View 와 View Model 간의 의존성은 사라진다.
  • Binding 기술 등이 프레임워크 특화이기 때문에 다른 프레임워크 로의 재사용은 어렵다.






댓글남기기

참고