응용 프로그램 서비스 계층 호출 데이터베이스 기능. 나쁜 건축?

대본:

• 스택 : Java, Spring, Hibernate.
• 모델 : 클라이언트 서버 응용 프로그램
• 패턴 : MVC (Model-View-Controller).

서비스 계층 클래스에는 세 가지 동작이 있습니다.

1. 일부 서비스는 메소드 내에 비즈니스 규칙이 있으며 지속성을 애플리케이션에 위임합니다. 처럼:

   EntityManager.save (entity);

2. 일부 서비스는 단순히 데이터베이스 함수를 호출합니다 (매개 변수 전달).

   CallableStatement cls = con.prepareCall ( "{call databaseFunction (args)}");

3. 일부 서비스에는 두 가지 동작 이 모두 있는 방법이 있습니다.

내 질문 :

1. 응용 프로그램 서비스에서 직접 데이터베이스 기능을 호출하는 데 문제가 있습니까? 이것이 나쁜 습관으로 간주되지 않습니까? 이와 같은 프로젝트에 적용 가능한 아키텍처 모델은 무엇입니까?
2. 동일한 서비스에서 동작을 혼합하는 데 문제가 있습니까? 거래 및 일관성과 같은?
3. 유지 관리의 경우이 캡슐화가 개발자에게 데이터베이스의 기능도 변경해야한다는 것을 모호하게합니까? 이것을 피하는 방법?
4. 이 시나리오는 전 세계의 다른 응용 프로그램에서 발생합니까 아니면 건축 오류일까요?

응용 프로그램 서비스에서 직접 데이터베이스 기능을 호출하는 데 문제가 있습니까? 이것이 나쁜 습관으로 간주되지 않습니까?

나는 생각합니다. 데이터베이스 내부에 대한 지식을 응용 프로그램 서비스에 배치하고 있습니다. 스토리지 엔진을 변경하거나 필드 이름을 바꾸거나 색인을 생성하는 방식으로 데이터베이스를 변경하면 응용 프로그램 서비스를 변경해야하고 SRP 를 위반하는 경우가 있습니다.

이와 같은 프로젝트에 적용 가능한 아키텍처 모델은 무엇입니까?

아래의 의견을 참조하십시오.

동일한 서비스에서 동작을 혼합하는 데 문제가 있습니까? 거래 및 일관성과 같은?

기술적 인 문제는 없다고 생각하지만 논리적 문제가 있습니다. 응용 프로그램에서 두 가지 접근 방식을 혼합하여 모호하고 덜 구조적이며 변경에 적응하기가 어렵습니다. SRP 위반에 대한 위의 의견도 참조하십시오.

유지 관리의 경우이 캡슐화가 개발자에게 데이터베이스의 기능도 변경해야한다는 것을 모호하게합니까?

물론입니다.

이것을 피하는 방법?

데이터베이스와 직접 작업하는 별도의 추상화 수준으로 DAO 계층 또는 간단한 리포지토리 패턴으로 작업하는 메서드 및 함수를 배치합니다 (응용 프로그램의 복잡성에 따라 다름)

이 시나리오는 전 세계의 다른 응용 프로그램에서 발생합니까 아니면 건축 오류일까요?

나는 세상에서 모든 일이 일어난다 고 생각합니다.)

당신이 말한 것에 따르면 서비스 계층이 있으므로 적합한 아키텍처 패턴은 계층 구조입니다. 추가 참조

예. 비즈니스 계층이 데이터베이스 추상화에만 액세스하는 방식으로 데이터 액세스 계층 이외의 데이터베이스에서 직접 데이터베이스 호출을 수행하는 것은 일반적으로 좋지 않습니다.

믹싱 비헤이비어와 관련하여 DAO 패턴 또는 리포지토리 패턴으로 일부 디자인 패턴을 사용하면 해당 책임을 위임하여 해당 코드를 개선하는 데 도움이 될 수 있습니다.

디자인 패턴과 ORM을 사용하면 얻을 수있는 이점 중 일부는 코드를 쉽게 읽을 수있게되어 책임을 캡슐화하므로 데이터베이스 액세스가 변경되면 비즈니스 계층이 크게 바뀌지 않아야한다는 것입니다.