나는 꽤 표준적인 웹/서비스/데이터 액세스 레이어 디자인을 사용하여 재미/학습을위한 작은 웹 사이트를 구축 중이다.자바 웹 애플리케이션의 정적 레이어
내 서비스 계층/데이터 액세스 계층 클래스의 인스턴스를 계속 만들어야하는 번거 로움을 덜어주기 위해 모든 메서드를 정적으로 만들었습니다. 로컬 변수 등을 사용하면서 동시성 문제를 일으켜서는 안되며 모든 리소스를 공유하지 않아야합니다.
내가 알 수있는 한, 이것은 실제로 진정한 OO 접근법을 따르고 있지는 않지만, 코드를 훨씬 더 깨끗하게 유지한다는 것입니다.
실용적인 방법이 아닌 이유가 있습니까? 어떤 종류의 문제가 나중에 발생할 수 있습니까? 필요에 따라 서비스 및 데이터 레이어 클래스 인스턴스를 반환 할 수있는 "팩토리"클래스를 갖는 것이 더 낫습니까?
단점 :
당신이 중 하나에 의해 비 정적 비즈니스/데이터 액세스 계층 클래스가는 더 나을 것 :
응용 프로그램에 연결된 각 사용자/세션이 자체 스레드에서 실행되므로 웹 응용 프로그램이 본질적으로 멀티 스레드가됩니다.
여러 사용자가있는 모든 정적 메서드에 동시성 문제가 있다고 생각합니다. 웹 레이어는 동시 사용자를 처리합니다. 모든 정적 메서드가 이것을 처리 할 수 있습니까? 아마도, 그러나 그들은 끊임없이 단일 파일에서 요청을 대기열에 잠겨 있지 않을까요? 나는 너의 생각을 결코 시도하지 않았다.
"놀이기구에 항상 손과 발을 유지하십시오"라고 말한 놀이 공원에서의 놀이기구를 알고 있습니까? 당신이하지 않으면 타는 것이 훨씬 더 재미 있다는 것이 밝혀졌습니다. 유일한 진정한 트레이드 오프는 당신이 진정한 지키기 - 손과 발을 내주는 방식을 실제로 따르지 않고 있다는 것입니다.
요점은 이렇습니다 - 손과 발을 타고있는 곳에 두는 이유가있는 것처럼 "진정한 OO 접근법"을 따라야하는 이유가 있습니다 - 어디서나 출혈이 시작될 때까지는 큰 즐거움입니다.
당신이 묘사하는 방식대로, 이것은 "잘못된"접근법이 아니지만 피하려고하는 문제를 실제로 보지 못합니다. 서버가 시작될 때 이러한 비즈니스 객체의 단일 인스턴스를 생성하고 필요에 따라이를 서블릿에 전달할 수 없습니까?
OO를 창 밖으로 던질 준비가되면 싱글 톤 패턴을 체크 아웃 할 수 있습니다.
나는 디자인에 이점이별로 없으며 잘못 될 수있는 많은 것들이 있습니다. 한 줄의 코드를 저장하고 있습니까? 여기에 당신의 접근 방식에 몇 가지 단점이있다 :
한 줄의 코드의 누락 BU는 것을 정말 볼 수 없습니다 너에게 아무것도 안겨 줬어.
사실 "OO 디자인"문제는 아니지만 더 적절한 것입니다. 왜 그런 절차 적 방법으로 자바를 사용하고 있습니까? 분명히 PHP는 이런 종류의 디자인에 더 적합 할 것입니다 (실제로 컴파일하고 배포하지 않아도되므로 시간을 절약 할 수 있습니다).
저는 비즈니스 계층을 비 정적으로 설정합니다. 애플리케이션을 유지, 변경 및 발전시키는 것이 훨씬 쉬워 질 것입니다.
이러한 유형의 아키텍처로 개체를 단위 테스트하는 데 어려움이있을 수 있습니다. 예를 들어 정적 데이터 액세스 계층을 참조하는 비즈니스 개체 계층이있는 경우 모의 데이터 액세스 개체를 쉽게 사용할 수 없으므로 비즈니스 계층을 테스트하기가 어려울 수 있습니다. 즉, 비즈니스 계층을 테스트 할 때 데이터 액세스 계층에서 "실제"메서드를 사용하지 않으려는 것은 데이터베이스에 원치 않는 변경을 가할 수 있기 때문입니다. 데이터 액세스 계층이 정적이 아닌 경우 테스트 목적으로 모의 데이터 액세스 개체를 비즈니스 계층에 제공 할 수 있습니다.