3-tier 아키텍처의 정확성

Question

(결함이있는) 3-tier 아키텍처로 구현 된 프로젝트가 있습니다. 제 직업은 프로젝트에 새로운 데이터베이스를 추가하기 쉽도록 좀 더 일반화하고 있습니다.

콘크리트 : SQL 데이터베이스를위한 databaseFacade가 있습니다. 그래서 우리는 여러 데이터베이스를 매우 쉽게 추가 할 수 있도록 좀 더 일반화해야합니다. 이 경우 CSV 파일에 기록하십시오.

데이터베이스 계층에서 내 아이디어는 모든 메서드가 정의 된 인터페이스를 만드는 것이 었습니다. 그런 다음 데이터베이스 인터페이스를 사용하여 (사용하고자하는 것에 따라 다름)이 인터페이스를 구현하여 더욱 일반적으로 사용하십시오. 그런 다음 DBmanager 클래스가 있습니다. 이 DBmanager 클래스는 사용할 데이터베이스를 알 수 있도록 구성 파일을 읽습니다. 이 정보를 바탕으로 그는 인터페이스의 인스턴스를 생성하고이를 애플리케이션 레이어에 반환합니다.

그러나 이것이 내가 올바른지는 알 수 없습니다. 이제 응용 프로그램 계층에는 DBmanager 클래스가 있습니다 (모든 요소가 올바르게 캡슐화 된 경우 1 개의 메서드가 공용으로 반환 됨). 그런 다음 DBfacade가 반환됩니다.

정확성에 대한 의견이 있으십니까? 나는 의심의 여지가 있기 때문에.

Answer 1

나에게는 합법적 인 것처럼 보입니다. 필자는 소프트웨어 아키텍처의 전문가는 아니지만, JDBC가 설계된 방식과 비슷한 개념을 설명합니다.

Answer 2

PHP 시스템 (Moodle)이이 패턴을 거의 사용한다는 것을 보았지만 제대로 작동합니다. 일어나는 모든 일은 DB 유형이 구성 변수로서 지정되고 구체적인 DB 액세스 클래스가 글로벌 DB 관리자 객체로서 인스턴스화되어 외관 방법을 제공하는 것이다. get_records() : 행 객체의 표준화 된 배열을 반환합니다. 당신이이 외관이나 어댑터라고 부를 지에 대해서는 의문의 여지가 있지만, 그것은 거의 걱정하지 않습니다.

나는 현재 계획대로 진행할 것이라고 말하고 싶습니다. 레이어를 적절히 분리하고 패턴의 목적을 이해 한 것 같습니다. 또한 로우 레벨 (DB) 및 하이 레벨 (어플리케이션 컨트롤러) 구성 요소가 중간에 단일 DB 파사드 인터페이스에 의존하는 방식은 dependency inversion의 좋은 예이므로 보너스 포인트가됩니다! :)

Answer 3

올바른 방법입니다. 하나의 작은 단서는 DBManager가 실제로 Factory 패턴을 따르므로, Facade 클래스가 DatabaseFacade라고 가정 할 때 DatabaseFacadeFactory라고해야합니다.

Java에 익숙해지면 Spring을 확인하십시오. 이 같은 상황을 자동으로 처리하고 많은 상용구 코드의 필요성을 없애주는 많은 도구와 기술을 제공합니다. 자세한 내용은 dependency-injection을 참조하십시오.