2011-09-01 4 views
1

DML SQL 문을 작성하는 데 사용되는 빌더 패턴을 보았습니다. 어떤 패턴이 SQL DDL 문을 작성하는 데 더 적합할까요? 나는 (전적으로 자기 교육 목적 DB 도구) 간단한 프로그램에 대해 생각하고SQL DDL 문 작성 : 어떤 패턴이 적절합니까?

, 그 만들 것입니다 (동적) 간단한 SQL의 DDL 문. 어떤 패턴을 고려해야하는지 잘 모르겠습니다.

팩토리 패턴을 사용하면 구체적인 데이터베이스 공급자 클래스 라이브러리에서 클라이언트 코드를 분리 할 수 ​​있습니다. 나는 그것이 명백한 선택이라고 생각한다. (내가 잘못하면 나를 바로 잡아라.) 데코레이터 패턴은 SQL 문을 작성하기위한 첫 번째 선택 이었지만 몇 가지 예제를 코딩 한 다음 this answer을 읽은 다음에는 객체를 작성하고 이미 작성된 객체를 꾸미지 않으므로 데코레이터를 사용하지 않아야합니다.

그래서 어떤 패턴을 고려해야합니까? 그리고이 패턴이 좋은/좋은 이유는 무엇입니까?

설명을 위해으로 업데이트되었습니다.

+0

응용 프로그램이 DDL을 동적으로 작성해야하는 경우는 거의 없습니다. 당신이 DB 도구를 쓰지 않는 한. 이것이 가장 적절한 디자인이라고 확신합니까? –

+0

예, 저는 DB 도구에 대해 생각하고있었습니다. 그렇습니다. DDL 문은 동적으로 생성 될 것입니다. – qlf00n

답변

0

DB 도구의 "핵심"은 소유하고있는 지식을 DB 독립적 인 형식으로 나타내야하며, 시간이되면 데이터베이스 관련 코드가 해당 지식을 DB 관련 DDL로 변환합니다.

이렇게하려면 일종의 의존성 주입이 필요할 것입니다. 기본 아이디어는 애플리케이션의 핵심이 인터페이스에서만 작동하며 이러한 인터페이스에서 선언 된 것 이상을 결코 알지 못합니다. 런타임에 이러한 인터페이스를 구현하는 DB 관련 객체가 인스턴스화되어 코어에 "주입"됩니다. 동일한 인터페이스 세트를 구현하는 다른 객체 세트처럼 맹목적으로 "호출"하는 것보다 생성하십시오.

다른 DB를 지원해야하는 경우 jut은 이러한 인터페이스를 구현하고 런타임에 인스턴스를 생성하는 또 다른 클래스 집합을 만듭니다.

물론 이것은 모두 하나의 이론입니다. 당신은 다른 데이터베이스 시스템들 사이에 많은 미묘한 차이가 있다는 것을 알게 될 것입니다. 나는 완전히 일반화 된 방식으로 모든 것을 표현하는 것이 어렵다고 생각합니다 ...