태그 : fowler

[번역] 제어 역전 컨테이너와 의존성 주입 패턴 (1/4)

마틴 파울러(Martin Fowler)

자바 커뮤니티에서는 줄곧 경량 컨테이너들이 경쟁적으로 출시 되고 있습니다. 이들은 다른 프로젝트에서 가지고 온 S/W 부품을 조립해서 하나로 통합된 응용 S/W를 만드는 데 도움이 됩니다. 이 컨테이너들은 S/W 부품들을 연결하는 방법에 대한 공통 패턴을 근간으로 하고 있습니다. 이 개념을 흔히 제어 역전(Inversion of Control)이라고 부릅니다. 이 글에서는 이 패턴을 의존성 주입(Dependency Injection)과 서비스 위치탐색기(Service Locator)로 세분화하고 이들을 비교함으로 이 패턴의 작동 방식을 파고들어보려고 합니다. 이 두 가지 방식 중 어떤 것을 선택할지 논하는 것보다 S/W 부품를 이용하는 코드에서 설정을 분리하자는 원칙이 더 중요합니다.

주류 J2EE의 대안을 만들려는 엄청난 규모의 활동은 기업용 자바 세상에서 흥미있는 일 중 하나입니다.그 중 많은 수가 오픈 소스에서 일어나고 있습니다. 상당수는 무겁고 복잡한 주류 J2EE 세상에 대한 반발이지만 다수는 대안을 찾으려는 탐구와 창의적인 시도이기도 합니다. 어떻게 각기 다른 요소를 함께 연결할 것인지를 다루는 것, 예를 들어 서로를 잘 알지 못하는 여러 팀에서 각자 만든 웹 컨트롤러 아키덱처와 데이터베이스 인터페이스를 어떻게 하나로 묶을 것인지가 이것들이 해결하려는 공통 사안입니다. 다수의 프레임워크가 이 문제를 해결했고 그중 몇몇은 다른 계층의 컴포넌트들을 조립하는 일반적인 기능까지 제공하는데 이르렀습니다. 이들을 종종 경량 컨테이너라고 부르는데 피코 컨테이너와 스프링을 예로 들 수 있습니다.

이 컨테이너들은 인상적인 몇가지 설계 원칙에 기초하고 있습니다. 이 원칙들은 특정 컨테이너는 물론 자바라는 플렛폼까지 넘어서 적용될 수 있습니다. 여기서 이 원칙 중 몇가지를 탐구해보려 합니다. 예로 사용한 언어는 자바이지만 내가 썼던 다른 원칙들 대부분이 그런 것처럼 다른 객체지향 환경(특히 .Net)에도 적용할 수 있습니다.

S/W 구성 요소들을 하나로 묶는 주제를 다루려면 서비스와 컴포넌트라는 두 단어를 둘러싼 껄끄러운 용어 문제 먼저 해결해야 할 것 같습니다. 이 둘의 정의와 관련된 길고 모호한 글들을 쉽게 찾을 수 있습니다. 저는 여기서 제가 이 단어를 어떤 의미로 사용하는지 말하려고 합니다.

전 컴포넌트를 재사용되는 소프트웨어 덩어리를 의미할 때 사용합니다. 컴포넌트는 컴포넌트 제작자가 어떤 영향도 끼칠 수 없는 응용 소프트웨어에 변경 없이 재사용 할 수 있습니다. 여기서 '변경 없이'라고 한 건 응용 소프트웨어가 컴포넌트 제작자가 허용한 방법으로 컴포넌트를 확장해서 행위를 바꾸어 사용할 수는 있을지언정  컴포넌트의 소스 코드를 고치지는 않는다는 것을 뜻합니다.

서비스는 외래 애플리케이션이 사용한다는 측면에서는 컴포넌트와 비슷합니다. 주요 차이점이라면 컴포넌트가 (jar 파일, 조립, DLL, 소스코드 삽입등 같이) 지역적으로 사용될 것이라 보는 반면에 서비스는 동기 방식이든 (웹 서비스, 전문 시스템, RPC, 소켓 등) 비동기 방식이든 모종의 인터페이스를 사용해 원격에서 사용 되리라는 것입니다.

이 글에서는 대부분 서비스라고 쓰겠지만 상당수의 논리는 지역적 컴포넌트에도 똑같이 적용될 수 있습니다. 사실 원격 서비스를 쉽게 사용하려면 흔히 로컬 컴포넌트 프레임워크 같은 것이 필요합니다. 컴포넌트냐 서비스냐에 대해 논하는 글은 읽는 것도 쓰는 것도 피곤한 일입니다. 그리고 요즘은 서비스가 훨씬 더 인기있습니다.

순진한 예제

모든 것을 분명하게 하고자 실행 가능한 예제 하나를 사용하려 합니다. 제가 흔히 쓰는 예제가 그렇듯 이 예제도 엄청나게 단순합니다.  비현실적으로 보일 만큼 작지만 복잡한 실제 예의 수렁에 빠지는 일 없이 뭐가 어찌 돌아가는지 눈으로 확인할 수 있는 정도는 되리라 생각합니다.

예제는 특정 감독이 연출한 영화의 목록을 찾아주는 컴포넌트 입니다. 이 놀랍도록 유용한 기능이 메소드 하나로 구현되어 있습니다.

class MovieLister...
    public Movie[] moviesDirectedBy(String arg) {
        List allMovies = finder.findAll();
        for (Iterator it = allMovies.iterator(); it.hasNext();) {
            Movie movie = (Movie) it.next();
            if (!movie.getDirector().equals(arg)) it.remove();
        }

        return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]);
    }

기능 구현이 극단적으로 단순합니다. 보유하고 있는 모든 필름 정보를 달라고 (조금 있다 얻게 될) 찾기 객체에게 요청합니다. 그리고 목록을 뒤쳐 반환할 특정 감독의 작품을 뒤집니다. 이 순진한 코드는 단지 이 글에서 진짜 다루려고 하는 내용을 위한 골격에 지나지 않으므로 손대지 않을 겁니다.

이 글에서 진짜로 관심 있는 것은 찾기 객체, 특히 MovieLister와 특정 찾기 객체를 연결하는 방법입니다. 이것이 흥미있는 이유는 이 멋진 movieDirectedBy 메소드가 영화를 보관하는 방식과 전혀 상관 없이 움직였으면 하기 때문입니다. 그래서 메소드는 단지 찾기 객체를 참조하기만 하면 되고 그 파인더는 findAll 메소드 호출에 어떻게 응답해야하는지 알기만 해도 되었으면 합니다. 찾기 객체의 인터페이스를 정의하는 것으로 이것을 실현할 수 있습니다.

public interface MovieFinder {
    List findAll();
}

이제 이렇게 해서 결합이 잘 분리되었습니다. 하지만 어느 지점에선가 실제 영화 목록을 얻으려면 구상 클래스를 얻어야 합니다. 한번 생성자에 이 코드를 넣어보겠습니다.

class MovieLister...
  private MovieFinder finder;
  public MovieLister() {
    finder = new ColonDelimitedMovieFinder("movies1.txt");
  }

구현 클래스의 이름은 콜론으로 구분되어 있는 텍스트 파일에서 목록을 얻으려고 한다는 뜻입니다. 단지 어떤 구현체가 있다는 사실만이 중요하므로 상세한 부분은 생략하겠습니다.

이 클래스를 혼자서만 쓴다면 모든 것이 훌륭하고 멋집니다. 그런데 친구들이 이 멋진 기능을 쓰고 싶은 열망에 압도되어 이 프로그램를 복사해달라고 할 때 어떤 일이 일어날까요? 그 친구들도 "movies1.txt"라는 파일에 콜론으로 구별된 형태로 영화 목록을 보관하고 있다면 모든 것이 환상적이겠죠. 만약 영화 목록 파일의 이름이 다르다면 설정 파일에 파일 이름을 넣도록 해서 쉽게 해결할 수 있습니다. 그런데 만약 완전히 다른 형태로 영화 목록을 저장하고 있다면 어떨까요? SQL 데이터베이스나 XML이나 웹 서비스나 형식이 다른 텍스트 파일이면 말입니다. 이 경우에는 다른 클래스로 데이터를 얻어 와야 합니다. 이미 MovieFinder 인터페이스를 정의 했기 때문에 moviesDirectedBy 메소드를 바꾸지 않아도 됩니다. 그렇지만 여전히 올바른 finder 구현물의 인스턴스를 얻어 제자리에 두는 어떤 방법이 필요합니다.

그림 1 : 목록 클래스에서 단순히 생성했을 때 의존성 관계

그림 1에서 지금의 의존 관계를 볼 수 있습니다. MovieLister 클래스는 MovieFinder 인터페이스와 그 구현물에 종속되어 있습니다. 인터페이스에만 종속되어 있으면 좋겠는데 어떻게하면 인스턴스를 가져와 쓸 수 있을까요?

P of EAA에는 이런 상황을 Plugin 패턴으로 설명하고 있습니다. 컴파일 시점에는 찾기 객체의 구현 클래스가 프로그램에 연결되어 있지 않습니다. 친구들이 어떤 것을   쓰려는지 모르기 때문입니다. 대신 목록 객체가 어떤 구현물과도 작동되고 나중에 언젠가 그 구현물을 별 조작없이 장착할 수 있으면 좋겠습니다. 문제는 어떻게 우리의 목록 객체가 구현 클래스에 대해 잘 모르면서도 여전히 인스턴스와 협력하여 해야 할일을 할 수 있도록 하느냐는 것입니다.

이것을 실제 시스템으로 확대해서 보겠습니다. 실제 시스템에서는 이런 서비스와 컴포넌트가 수십개나 있을 것입니다. 이 컴포넌트들의 사용하는 곳마다 인터페이스를 통해 호출하도록 추상화 할 수 있습니다. 만약 컴포넌트가 그 인터페이스에 맞지 않다면 어댑터를 써야겠죠. 하지만 만약 이 시스템을 여러가지 다른 방식으로 배포하기 원한다면 이 서비스들과의 상호작용할 수 있도록 처리하기 위해 플러그인을 사용해야 합니다. 그러면 여러 다른 구현물은 여러 다른 배포 환경에서 사용할 수 있습니다.

이제 핵심 문제는 이 여러 플러그인들을 어떻게 조립해서 한 애플리케이션으로 만들 수 있느냐는 것입니다. 이것이 새로운 경량 컨테이너들이 해결하려고 하는 주된 문제 영역 중 하나입니다. 그리고 보편적으로 제어 역전을 그 해법으로 사용합니다.

제어 역전


경량 컨테이너들을 소개할 때에 왜 그것들이 유용한지를 말하면서 이유가 "제어 역전"을 구현했기 때문이라고 할 때면 전 무척 당황스럽습니다. "제어 역전"은 프레임워크들이 갖는 공통적인 특성입니다. 그렇기에 경량 컨테이너들이 자기들은 제어 역전을 쓰기 때문에 특별하다고 말하는 건 마치 내 차에는 바퀴가 있어서 특별하다고 하는 것과 같습니다.

질문해야 할 것은 어떤 제어를 역전하려고 하느냐는 것입니다. 제가 처음 접했던 제어 역전은 유저 인터페이스의 중심 제어에서였습니다. 초기 유저 인터페이스들은 애플리케이션 프로그램에서 제어를 했습니다. 흔히 "이름을 입력하시오", "주소를 입력하시오" 같은 일련의 명령 문구를 가지고 있고 프로그램이 이것들을 하나씩 물어보고는 답을 입력 받곤 했습니다. 그래픽(몇몇 스크린 기반도) 유저 인터페이스에서는 유저 인터페이스 프레임워크가 제어권을 가지고 있고 프로그램은 화면의 각 요소에 대한 이벤트 처리자만 마련하고 있으면 됩니다.  프로그램의 주 제어권은 역전된 것입니다. 애플리케이션에서 프레임워크로 옮겨진 것이지요.

이 새로운 컨테이너들에서의 역전은 플러그인 구현물을 찾을 방법과 관련되어 있습니다. 우리의 순진한 예제에서 목록 객체는 찾기 구현물의 인스턴스를 직접 생성해서 씁니다. 이렇게 하면 찾기 객체를 플러그인이라고 할 수 없습니다. 경량 컨테이너들이 사용하는 접근법은 플러그인을 사용하는 누구라도 어떤 관례를 따르기만 하면 독립된 조립 모듈이 구현물을 목록 객체에 주입하도록 보장합니다.

결국 이런 패턴을 지칭하는 보다 지협적인 이름이 필요한 것 같습니다. 제어 역전은 너무 일반적인 용어라서 사람들이 혼란스러워 합니다. 다양한 IoC 지지자들과 많은 토론을 한 결과 의존성 주입이라고 부르기로 합의하였습니다.

이제 여러가지 형태의 의존성 주입에 대해서 말하려고 하지만 여기서 확실해 해두고 싶은 것은 이것이 플러그인 구현물에서 애플리케이션 클래스의 의존성을 제거하는 유일한 방법이 아니라는 것입니다. 의존성 제거에 쓸 수 있는 다른 패턴으로 서비스 위치탐색기가 있습니다. 이에 대해서는 의존성 주입을 설명하고 나서 다루겠습니다.

[번역] 제어 역전 컨테이너와 의존성 주입 패턴 [1][2][3][4]

---------

워낙 유명한 글이지만 막상 이 글을 읽는 사람도 IOC나 DI의 의미를 이해하고 쓰는 사람이 많지 않은 것 같습니다. 스프링을 쓰는 몇몇 프로젝트에 참여해서 일해본 적이 있지만 매번 스프링을 이런식으로 쓰는 게 무슨 의미인가? 하는 회의만 들었습니다. 그래서 출퇴근 시간에 조금씩 번역해서 올려보려고 합니다. 대충 보니 네 부분으로 나눌 수 있을 것 같습니다. 

by 박성철 | 2009/09/28 00:37 | 프로그래밍 이야기 | 트랙백 | 덧글(0)

[간이번역] Mapping to Relational Databases

http://www.informit.com/articles/article.aspx?p=30661&rl=1

P of EAA의 DB관련 패턴들을 어떻게 써야 하는지 알 수 있는 좋은 글 같아서 퍼왔습니다.
중간 중간 중요한 부분만 대략 번역해볼께요.
시간도 없고...

----------------------------------------------------------------------------------

Enterprise Application Architecture: Mapping to Relational Databases

* By Martin Fowler.
* Jan 24, 2003
* Sample Chapter is provided courtesy of Addison Wesley Professional

데이터베이스가 아주 많이 쓰이고 중요해서 이것과 커뮤니케이션 하는게 큰 문제다.

The role of the data source layer is to communicate with the variouspieces of infrastructure that an application needs to do its job. Adominant part of this problem is talking to a database, which, for themajority of systems built today, means a relational database. Certainlythere's still a lot of data in older data storage formats, such asmainframe ISAM and VSAM files, but most people building systems todayworry about working with a relational database.

관계형 DB가 성공한 큰 이유 중 하나는 SQL이다. 표준이지만 벤더마다 다르기도...

One the biggest reasons for the success of relational databases isthe presence of SQL, a mostly standard language for databasecommunication. Although SQL is full of annoying and complicatedvendor-specific enhancements, its core syntax is common and wellunderstood.

Architectural Patterns

P fo EAA의 첫 패턴 묶음은 도메인 로직이 DB에 접근하는 방법에 대한 것이다. 여기서 선택한 것이 계속 영향을 미치니 신중해야 한다.

The first set of patterns comprises the architectural patterns,which drive the way in which the domain logic talks to the database.The choice you make here is far-reaching for your design and thusdifficult to refactor, so it's one that you should pay some attentionto. It's also a choice that's strongly affected by how you design yourdomain logic.

SQL이 유명하지만 많은 개발자들이 SQL을 모른다. SQL을 코드에 넣으면 복잡하고 유지보수와 테스트 하기 힘들다. DBA들은 SQL을 뽑아보기 원한다.

Despite SQL's wide spread use in enterprise software, there are still pit falls in using it. Many application developers don't understand SQL well and, as a result, have problems defining effective queries and commands. Although various techniques exist for embedding SQL in a programming language, they're all some what awkward. It wouldbe better to access data using mechanisms that fit in with the application development langauge. Database administrations (DBAs) alsolike to get at the SQL that accesses a table so that they can understand how best to tune it and how to arrange indexes.

이런 이유로 SQL을 도메인 로직에서 분리해 다른 클레스에 저장하는게 좋다. 좋은 방법은 DB의 테이블 구조에 맞게 클레스들을 구성하는 것이다. 이들 클레스들은 테이블에 대한 Gateway(466)의 형태가 될 것이다. 나머지 어플리케이션은SQL에 대해 알 필요가 없다.

For these reasons, it's wise to separate SQL access from the domainlogic and place it in separate classes. A good way of organizing these classes is to base them on the table structure of the database so that you have one class per database table. These classes then form a Gateway (466) to the table. The rest of the application needs to know nothing about SQL, and all the SQL that accesses the database is easy to find. Developers who specialize in the database have a clear placeto go.

Gateway(466)을 어떻게 사용할지는 두가지 주요 방법이 있다. 가장 분명한 방법은 쿼리의 결과로 얻은 각 열이 한 인스턴스를 갖게하는 것이다. Row Data Gateway(152)
데이터를 중심으로 사고하는 객체지향에 본질적으로 부합하는 방법이다.

There are two main ways in which you can use a Gateway (466). The most obvious is to have an instance of it for each row that's returned by aquery (Figure 3.1). This Row Data Gateway (152) is an approach that naturally fits an object-oriented way of thinking about the data.

많은 환경이 Record Set(508)을 제공한다. 이는 테이블과 열(row)를 표현하는 일반적인 데이타 구조이다. Record Set(508)을 사용할 경우 테이블당 한 클레스만 필요하다. Table Data Gateway(144)는 DB를 쿼리해 Record Set(508)을 반환하는 메소드를 제공한다.

Many environments provide a Record Set (508)?that is, a generic data structure of tables and rows that mimics the tabular nature of adatabase. Because a Record Set (508) is a generic data structure,environments can use it in many parts of an application. It's quite common for GUI tools to have controls that work with a Record Set(508). If you use a Record Set (508), you only need a single class for each table in the database. This Table Data Gateway (144) (see Figure3.2) provides methods to query the database that return a Record Set(508)

난 간단한 어플리케이션에서도 Gateway 패턴을 쓰는 경향이 있다. SQL과 도메인 로직의 명박한 구별은 매우 도움이 된다.

Even for simple applications I tend to use one of the gate way patterns. A glance at my Ruby and Python scripts will confirm this. Ifind the clear separation of SQL and domain logic to be very helpful.

Table Module(125)를 선택했다면 Table Data Gateway(144)Record Set(508)를 쓰는 것은 잘 맞는 것이 사실이다. 이것은 stored procedure을 염두에 둘 때에도 사용 할 수 있는 패턴이다. 많은 설계자들이 명시적인 SQL 구문 대신 stored procedure를 사용하기 좋아한다. 이럴 때 Table DataGateway(144)를 써서 stored procedure 호출을 캡슐화 하는게 좋다.

The fact that Table Data Gateway (144) fits very nicely with RecordSet (508) makes it the obvious choice if you are using Table Module(125). It's also a pattern you can use to think about organizing stored procedures. Many designers like to do all of their database access through stored procedures rather than through explicit SQL. In this case you can think of the collection of stored procedures as defining a Table Data Gateway (144) for a table. I would still have an in-memory Table Data Gateway (144) to wrap the calls to the stored procedures,since that keeps the mechanics of the stored procedure callencapsulated.

만약 Domain Model (116)을 사용한다면 가지고 놀 수 있는 몇가지 옵션이 더 있다. 물론 Row Data Gateway(152)이나 Table Data Gateway(144)Domain Model(116)과 함께 사용할 수도 있다. 하지만 내 입에는 이 방법이 지나치게 간접적이거나 오히려 불충분하게 보일 때가 있다.

If you're using Domain Model (116), some further options come into play. Certainly you can use a Row Data Gateway (152) or a Table Data Gateway (144) with a Domain Model (116). For my taste, however, that can be either too much indirection or not enough.

간단한 어플리케이션에서 Domain Model(116)은 복잡하지 않은데 사실 상 한 테이블 당 한 도메인 클레스로 구성한다. 이런 도메인 객체는 종종 그리 복잡하지 않은 비지니스 로직만 갖는다. 이런 경우 각 도메인 객체가 데이터베이스를 읽거나 쓰는 책임을 갖는게 합리적이다. 이것이 바로 Active Record(160)이다. Active Record(160)을 다른 관점에서 생각해 보면 이것은 먼저 Row Data Gateway(152)를 만들고 이 클레스에 도메인 로직을
추가하는 - 특히 여러Transaction Scripts(110)에 걸쳐 있는 중복된 코드를 보게 되었을 때 - 것이 된다.

In simple applications the Domain Model (116) is an uncomplicatedstructure that actually corresponds pretty closely to the databasestructure, with one domain class per database table. Such domain objects often have only moderately complex business logic. In this case it makes sense to have each domain object be responsible for loading and saving from the database, which is Active Record (160) (see Figure3.3). Another way to think of the Active Record (160) is that you start with a Row Data Gateway (152) and then add domain logic to the class, particularly when you see repetitive code in multiple TransactionScripts (110).

이런 종류의 상황에서 Gateway(466)를 사용한 간접적인 처방은 큰 도움이 안된다.
도메인 로직이 보다 복잡해지면서 리치 Domain Model(116)을 향해 나아가게 된다. 간단한 접근 방법은 Active Record(160)을 쪼개기 시작하는 것이다. 도메인 로직을 보다 작은 클래스로 인수분해 하면서  테이블과의 1:1 대응은 약해지기 시작한다. 관계형 DB는 상속을 지원하지 않으니까 GOF의 스트레이티지 패턴이나 다른 멋진 OO 패턴을 쓰기 힘들어진다. 도메인 로직이 깐깐해져가면서 당신은 언제나 DB와의 연동 없이 이를 테스트 할 수 있기 원할 것이다.

In this kind of situation the added indirection of a Gateway (466) doesn't provide a great deal of value. As the domain logic gets more complicated and you begin moving toward a rich Domain Model (116), the simple approach of an Active Record (160) starts to break down. The one-to-one match of domain classes to tables starts to fail as you factor domain logic into smaller classes. Relational databases don't handle inheritance, so it becomes difficult to use strategies [Gang ofFour] and other neat OO patterns. As the domain logic gets feisty, you want to be able to test it without having to talk to the database all the time.

이 모든 것들이 Domain Model(116)이 점점 커져가면서 간접적이 되도록 압력을 준다. 이런 경우 Gateway(466)가 몇가지 문제들을 해결해 주기는 하지만 Domain Model(116)과 DB 스키마가 겹합되는 문제가 여전히 남아 있다. 결과적으로 Gateway(466)의 필드를 도메인 객체의 필드로의 변환 작업이 생기고 이것이 도메인 객체를 복잡하게 만든다.

All of these forces push you to in'direction as your Domain Model(116) gets richer. In this case the Gateway (466) can solve some problems, but it still leaves you with the Domain Model (116) coupled to the schema of the database. As a result there's some transformation from the fields of the Gateway (466) to the fields of the domain objects, and this transformation complicates your domain objects.

보다 좋은 방법은 도메인 객체와 DB 테이블을 맵핑시키는 작업의 모든 책임을 담당하는 레이어를 만들어 DomainModel(116)와 DB를 완전히 격리 시키는 것이다. Data Mapper(165)Domain Model(116)과 DB간의 모든 읽고 쓰는 작업을 처리한다. 이것은 가장 복잡한 DB 맵핑 아키텍쳐이지만 두 레이어를 완전히 격리시키는 이점이있다.

A better route is to isolate the Domain Model (116) from thedatabase completely, by making your indirection layer entirelyresponsible for the mapping between domain objects and database tables.This Data Mapper (165) (see Figure 3.4) handles all of the loading andstoring between the database and the Domain Model (116) and allows bothto vary independently. It's the most complicated of the databasemapping architectures, but its benefit is complete isolation of the twolayers.

Domain Model(116)을 위한 최우선 영속화 메카니즘으로 Gateway(466)를 사용하도록 추천하지않는다. 도메인 로직이 단순하고 클래스와 테이블이 긴밀하다면 Active Record(160)가 단순한 방법이다. 보다복잡하다면 Data Mapper(165)가 필요하다.

I don't recommend using a Gateway (466) as the primary persistence mechanism for a Domain Model (116). If the domain logic is simple and you have a close correspondence between classes and tables, ActiveRecord (160) is the simple way to go. If you have something more complicated, Data Mapper (165) is what you need.

이 패턴들은 서로 간에 완전히 배타적이지는 않다. Data Mapper(165)를 기본적인 영속화 메카니즘으로 쓴다면 데이터 Gateway(466)을 외부 인터페이스를 다루듯 테이블이나 서비스를 감싸기 위해 사용할 수 있다.

These patterns aren't entirely mutually exclusive. In much of this discussion we're thinking of the primary persistence mechanism, by which we mean how you save the data in some kind of in-memory model to the database. For that you'll pick one of these patterns; you don't want to mix them because that ends up getting very messy. Even if you're using Data Mapper (165) as your primary persistence mechanism, however, you may use a data Gateway (466) to wrap tables or services that are being treated as external interfaces.

계속 테이블이라는 단어를 썼지만 뷰, stored procedure를 통해 캡슐화된 쿼리, 공통적으로 사용되는 다이나믹 쿼리들에 적용될 수 있다.

In my discussion of these ideas, both here and in the patterns themselves, I tend to use the word "table." However, most of thesetechniques can apply equally well to views, queries encapsulatedthrough stored procedures, and commonly used dynamic queries. Sadly,there isn't a widely used term for table/view/query/stored procedure,so I use "table" because it represents a tabular data structure. Iusually think of views as virtual tables, which is of course how SQLthinks of them too. The same syntax is used for querying views as for querying tables.

Updating obviously is more complicated with views and queries, asyou can't always update a view directly but instead have to manipulate the tables that underlie it. In this case encapsulating the view/querywith an appropriate pattern is a very good way to implement that updatelogic in one place, which makes using the views both simpler and more reliable.

One of the problems with using views and queries in this way is that it can lead to inconsistencies that may surprise developers whodon't understand how a view is formed. They may perform updates on two different structures, both of which update the same underlying tables where the second update overwrites an update made by the first. Providing that the update logic does proper validation, you shouldn't get inconsistent data this way, but you may surprise your developers.

가장 복잡한 Domain Model(116)까지도 영속화 할 수 있는 가장 단순한 방법은 OO DB를 쓰는 것이다.

I should also mention the simplest way of persisting even the mostcomplex Domain Model (116). During the early days of objects manypeople realized that there was a fundamental "impedance mismatch"between objects and relations. Thus, there followed a spate of efforton object-oriented databases, which essentially brought the OO paradigmto disk storage. With an OO database you don't have to worry aboutmapping. You work with a large structure of interconnected objects, andthe database figures out when to move objects on or off disks. Also,you can use transactions to group together updates and permit sharingof the data store. To programmers this seems like an infinite amount oftransactional memory that's transparently backed by disk storage.

OO DB는 생산성을 향상 시킨다.

The chief advantage of OO databases is that they improveproductivity. Although I'm not aware of any controlled tests, anecdotalobservations put the effort of mapping to a relational database ataround a third of programming effort?a cost that continues duringmaintenance.

대부분의 프로젝트가 OO DB를 사용하지 않는데 이유는 위험 때문이다. 관계 DB는 검증된 기술이다.

Most projects don't use OO databases, however. The primary reasonagainst them is risk. Relational databases are a well-understood andproven technology backed by big vendors who have been around a longtime. SQL provides a relatively standard interface for all sorts oftools. (If you're concerned about performance, all I can say is that Ihaven't seen any conclusive data comparing the performance of OOagainst that of relational systems.)

OO DB를 쓰지못한다 해도 Domain Model(116)을 사용한다면 O/R Mapping 도구를 사는 것을 심각하게 고려해야 한다. Data Mapper(165)를 만드는 것은 무지 복잡하다. 상용 O/R Mapper들은 좋다.

Even if you can't use an OO database, you should seriously considerbuying an O/R mapping tool if you have a Domain Model (116). While thepatterns in this book will tell you a lot about how to build a DataMapper (165), it's still a complicated endeavor. Tool vendors havespent many years working on this problem, and commercial O/R mappingtools are much more sophisticated than anything that can reasonably bedone by hand. While the tools aren't cheap, you have to compare theirprice with the considerable cost of writing and maintaining such alayer yourself.

관계 DB와 작업할 수 있는 OO DB 스타일 레이를 제공하는 움직임들이 있는데 Java에서는 JDO가 있지만 아직 초기라서 어떻게 될지 모르겠다.

There are moves to provide an OO-database-style layer that can workwith relational databases. JDO is such a beast in the Java world, butit's still too early to tell how they'll work out. I haven't had enoughexperience with them to draw any conclusions for this book.

하지만 도구를 사더라도 이 패턴들을 인식하는 것은 좋은 생각이다. 좋은 O/R 도구는 여러 옵션들을 제공하는데 이 패턴들은 선택하고 이해하는데 도움이 된다. 도구가 모든 수고를 날려 버릴 것으로 생각하지 말아라. 도구가 많이 완화시켜 주지만 여전히 O/R 도구를 사용하고 튜닝하는데 있어 작지만 중요한 일단의 작업이 남아있는 것을 발견 할 것이다.

Even if you do buy a tool, however, it's a good idea to be aware of these patterns. Good O/R tools give you a lot of options in mapping toa database, and these patterns will help you understand when to use thedifferent choices. Don't assume that a tool makes all the effort go away. It makes a big dent, but you'll still find that using and tuning an O/R tool takes a small but significant chunk of work.

by 박성철 | 2007/11/07 21:09 | 프로그래밍 이야기 | 트랙백 | 덧글(0)

◀ 이전 페이지다음 페이지 ▶