Framework (DBController)

파란색을 실험실로 간주했을때 dc는 실험실의 연결창구 역할을 하게 된다. Client는 기본적으로는 DBController(이하 dc)를 통해서 메시지 교환을 한다. 

DBController는 Facade 패턴의 예중 하나로 Facade(건물의정면) 패턴은 복잡한 서브 시스템에 통일된 인터페이스를 제공함으로써 복잡한 API를 단순화 시켜준다. 시스템을 서브 시스템 단위로 나누어 구성하는 것은 시스템의 복잡도를 낮춰주지만, 동시에 서브 시스템 사이에서의 통신 부하와 결합도가 증가하게 된다. 이러한 서브 시스템 사이의 의존도를 낮추고, 서브 시스템의 사용자 입장에서 사용하기 편리한 인터페이스를 제공하고자 하는 것이 facade 객체이다.

Facade 객체는 실생활에서의 고객 서비스 센터와 유사하다. 가령, 어떤 상품을 구매하는 과정에서 문제가 생겼다고 가정할 때, 고객이 문제의 성격에 따라 해당 부서에 직접 연락하는 것이 아니라 고객 서비스 센터를 통하는 것은 Facade 패턴에 대한 좋은 유추 사례가 될 수 있다.

여기서 DBController Facade 역할이 하는 일은 무엇일까 ?

첫째 복잡한 것을 단순하게 보여준다. 실험실 내부에서 작동하고 있는 내부에서 작동하고 있는 많은 클래스들의 관계나 사용법을 의식하지 않도록 해 준다. Java 접근자는 구조적인 이유로 public을 쓸수밖에 없는 경우가 종종 있는데 그중에 일부만 - 즉 개념적인 published 메소드 - 만을 노출시킴으로써 보이는 API를 적게 해 주고 단순하게 해 준다.

둘째 실험실의 컴포넌트로부터 클라이언트를 격리하여 실험실과 클라이언트 사이의 의존성을 낮춘다. 이런 캡슐화는 클라이언트와 서브시스템의 생존 기간이 다르기 때문에 필수적이다. Facade 패턴을 사용한다고 해도, 필요한 경우 실험실의 클래스에 직접 접근할 수도 있다.(이러한 것을 터널링이라고 부른다.) 즉, 일반화 정도(generality)와 개발의 편의성 사이에서의 적당한 합의점을 찾아야 한다.

Facade 패턴의 일반적인 특징에 추가로 위 DBController은 2가지를 더하고 있다.(SRP에는 위반되지만 ..) 첫번째는 실험실에서의 checked exception을 runtime exception으로 바꾼다. exception framework에서 말한대로 첫째로 대부분의 SQLException을 client에서는 잡아서 현명한 처리를 하지 않으며 둘째로 기껏해야 로그 기록하는 정도라면 본래 코드를 작성하는데 오히려 방해가 되기 때문이다. 이런 예외 처리가 현재 상황에서 적합하지 않다면 DC를 상속받아 해당 메소드를 재정의 하여야 한다.(실제 필요한적이 한번도 없었기 때문에 미리 만들어 두지 않았다.)

다른 한가지 역할은 Servant Filter 등록을 관리한다. 비실험실인 client는 현실의 요구사항이 있다. 이를테면 특정 쿼리의 실행을 모니터 하고 싶을 수도 있다.(느린 쿼리, 배치형 쿼리같은 특정 타입, 특정 테이블을 사용하는 쿼리 등등) 그리고 이 부분은 모두 필터로 관리되어 런타임중에 추가 삭제가 가능해야 한다. (나중에 다시 언급)


보통의 경우 Facade 객체는 Singleton 패턴으로 사용되는 경우가 많지만 DC의 경우 실제 커넥션 풀링등의 리소스 관리는 DBManager에게 맡기고 있으므로 배치 처리용으로 Servant가 없는 별도의 BatchDBController를 사용해도 되고 시간이 오래 걸리는 쿼리의 경우 비동기적으로 작동하는 AsyncDBController를 사용해도 된다.