자바 웹 애플리케이션의 정적 레이어


2

나는 꽤 표준적인 웹/서비스/데이터 액세스 레이어 디자인을 사용하여 재미/학습을위한 작은 웹 사이트를 구축 중이다.

내 서비스 계층/데이터 액세스 계층 클래스의 인스턴스를 계속 만들어야하는 번거 로움을 덜어주기 위해 모든 메서드를 정적으로 만들었습니다. 로컬 변수 등을 사용하면서 동시성 문제를 일으켜서는 안되며 모든 리소스를 공유하지 않아야합니다.

내가 알 수있는 한, 이것은 실제로 진정한 OO 접근법을 따르고 있지는 않지만, 코드를 훨씬 더 깨끗하게 유지한다는 것입니다.

실용적인 방법이 아닌 이유가 있습니까? 어떤 종류의 문제가 나중에 발생할 수 있습니까? 필요에 따라 서비스 및 데이터 레이어 클래스 인스턴스를 반환 할 수있는 "팩토리"클래스를 갖는 것이 더 낫습니까?

3

단점 :

  • 당신이 테스트 할 모의 데이터 액세스/비즈니스 로직 객체를 작성할 수 없습니다로 당신은 단위 테스트를 작성 할 수 없습니다.
  • 다른 스레드가 정적 코드에 동시에 액세스하려고하면 동시성 문제가 발생합니다. 또는 동기화 된 정적 메서드를 사용하면 정적 메서드를 사용하도록 큐에 대기하는 스레드로 끝납니다.
  • 인스턴스 변수를 사용할 수 없으므로 코드가 복잡해 지므로 제한 사항이됩니다.
  • 필요한 경우 비즈니스 또는 데이터 액세스 계층의 요소를 대체하는 것이 더 어려워집니다.
  • 이런 식으로 응용 프로그램을 작성하려면 PHP와 같이이 방법으로 작동하도록 설계된 언어를 사용하는 것이 더 낫습니다.

당신이 중 하나에 의해 비 정적 비즈니스/데이터 액세스 계층 클래스가는 더 나을 것 :

  • 싱글 톤 패턴 (각 클래스의 단일 인스턴스를 생성하고 스레드간에이를 공유)를 사용. ..
  • 또는 필요할 때마다 각 스레드에서 클래스의 인스턴스를 만듭니다.

응용 프로그램에 연결된 각 사용자/세션이 자체 스레드에서 실행되므로 웹 응용 프로그램이 본질적으로 멀티 스레드가됩니다.


-1

여러 사용자가있는 모든 정적 메서드에 동시성 문제가 있다고 생각합니다. 웹 레이어는 동시 사용자를 처리합니다. 모든 정적 메서드가 이것을 처리 할 수 ​​있습니까? 아마도, 그러나 그들은 끊임없이 단일 파일에서 요청을 대기열에 잠겨 있지 않을까요? 나는 너의 생각을 결코 시도하지 않았다.


4

"놀이기구에 항상 손과 발을 유지하십시오"라고 말한 놀이 공원에서의 놀이기구를 알고 있습니까? 당신이하지 않으면 타는 것이 훨씬 더 재미 있다는 것이 밝혀졌습니다. 유일한 진정한 트레이드 오프는 당신이 진정한 지키기 - 손과 발을 내주는 방식을 실제로 따르지 않고 있다는 것입니다.

요점은 이렇습니다 - 손과 발을 타고있는 곳에 두는 이유가있는 것처럼 "진정한 OO 접근법"을 따라야하는 이유가 있습니다 - 어디서나 출혈이 시작될 때까지는 큰 즐거움입니다.


4

당신이 묘사하는 방식대로, 이것은 "잘못된"접근법이 아니지만 피하려고하는 문제를 실제로 보지 못합니다. 서버가 시작될 때 이러한 비즈니스 객체의 단일 인스턴스를 생성하고 필요에 따라이를 서블릿에 전달할 수 없습니까?

OO를 창 밖으로 던질 준비가되면 싱글 톤 패턴을 체크 아웃 할 수 있습니다.


2

나는 디자인에 이점이별로 없으며 잘못 될 수있는 많은 것들이 있습니다. 한 줄의 코드를 저장하고 있습니까? 여기에 당신의 접근 방식에 몇 가지 단점이있다 :

  • 쉽게 여러 방법으로
  • 당신의 가정을 논리를 깨는 촉진하는 인스턴스 변수를 정의 할 수
  • 비즈니스 로직의 구현을 대체 할 수 있다는 멀티 스레드 문제가되지 않습니다 발생은
  • 쉽게 테스트를 위해 그들을 조롱 할 수없는 거의 확실히 잘못된

한 줄의 코드의 누락 BU는 것을 정말 볼 수 없습니다 너에게 아무것도 안겨 줬어.

사실 "OO 디자인"문제는 아니지만 더 적절한 것입니다. 왜 그런 절차 적 방법으로 자바를 사용하고 있습니까? 분명히 PHP는 이런 종류의 디자인에 더 적합 할 것입니다 (실제로 컴파일하고 배포하지 않아도되므로 시간을 절약 할 수 있습니다).

저는 비즈니스 계층을 비 정적으로 설정합니다. 애플리케이션을 유지, 변경 및 발전시키는 것이 훨씬 쉬워 질 것입니다.


0

이러한 유형의 아키텍처로 개체를 단위 테스트하는 데 어려움이있을 수 있습니다. 예를 들어 정적 데이터 액세스 계층을 참조하는 비즈니스 개체 계층이있는 경우 모의 데이터 액세스 개체를 쉽게 사용할 수 없으므로 비즈니스 계층을 테스트하기가 어려울 수 있습니다. 즉, 비즈니스 계층을 테스트 할 때 데이터 액세스 계층에서 "실제"메서드를 사용하지 않으려는 것은 데이터베이스에 원치 않는 변경을 가할 수 있기 때문입니다. 데이터 액세스 계층이 정적이 아닌 경우 테스트 목적으로 모의 데이터 액세스 개체를 비즈니스 계층에 제공 할 수 있습니다.