저장 프로 시저가 3 계층 분리를 위반합니까?

저의 일부 동료들은 데이터베이스에 저장 프로 시저에 비즈니스 로직이있는 것은 데이터베이스가 데이터 계층에 속하고 저장 프로시 저는 비즈니스 로직이기 때문에 3 계층 분리 아키텍처를 위반한다고 말했습니다.

저장 프로 시저가 없으면 세계는 매우 어두운 곳이라고 생각합니다.

그들은 실제로 3 계층 분리를 위반합니까?

동료들이 아키텍처를 구현과 혼동하고 있습니다.

다중 계층 응용 프로그램의 기본 개념은 특정 종류의 처리 (스토리지, 비즈니스 논리, 프레젠테이션)를 캡슐화하고 잘 정의 된 인터페이스를 사용하여 서로 통신하는 부분으로 나뉘어져 있다는 것입니다. 객체 지향이 아닌 언어로 객체 지향 프로그래밍과 유사한 작업을 성공적으로 수행 할 수있는 것처럼 데이터베이스 서버와 같은 한 환경 내에서 여러 계층으로 동일한 작업을 수행 할 수 있습니다. 이들 중 하나를 성공적으로 수행하는 것은 관리, 훈련 및 관련된 타협에 대한 이해가 필요합니다.

두 개의 계층이 데이터베이스에서 구현 된 3 계층 응용 프로그램을 살펴 보겠습니다.

• 데이터 계층이 : 네 개의 표준 테이블 조작을 사용하여 액세스 데이터베이스 테이블로 구성 ( INSERT, UPDATE, DELETE및 SELECT).
• 논리 계층 : 비즈니스 논리 만 구현하고 위에서 설명한 방법 만 사용하여 데이터 계층에 액세스하는 저장 프로 시저로 구성됩니다.
• 프리젠 테이션 계층 : 스토어드 프로 시저 호출 만 수행하여 로직 계층에 액세스하는 코드를 실행하는 웹 서버로 구성됩니다.

이것은 완벽하게 수용 가능한 모델이지만 일부 장단점이 있습니다. 비즈니스 로직은 데이터 티어에 빠르고 쉽게 액세스 할 수있는 방식으로 구현되며 데이터베이스 외부의 로직 티어가 "어려운 방법"으로 수행해야하는 작업을 수행 할 수 있습니다. 포기한 것은 계층을 다른 기술 및 평온한 구현으로 쉽게 옮길 수 있다는 것입니다. 즉, 계층이 데이터베이스에서 사용 가능한 기능을 사용하지 않고 정의 된 인터페이스 외부에있는 기능을 사용하지 않도록주의해야합니다. .

주어진 상황에서 이런 종류의 일과 그것이 가져 오는 타협이 용납 될 수 있는지 여부는 귀하와 동료가 귀하의 판단을 사용하여 결정해야합니다.

저장 프로시 저는 비즈니스 로직을 RDBMS 계층으로 가져 와서 3 계층 분리 위반을 코딩 할 수있을 정도로 강력합니다. 그러나 이것은 저장 프로 시저의 내재 된 결함이 아닌 귀하의 결정입니다. 응용 프로그램 논리를 아키텍처의 응용 프로그램 계층에 유지하면서 SP가 데이터 계층의 요구를 처리하도록 제한 할 수 있습니다.

비즈니스 논리를 포함하기 위해 저장 프로 시저 (특히 트리거 그룹)가 필요한 경우 분리 규칙에는 드물지만 중요한 예외가 있습니다. 이는 애플리케이션이 수백만 행에 닿는 즉각적인 데이터 집계를 많이 생성해야 할 때 발생합니다. 이와 같은 경우 비즈니스 계층 사용을 위해 사전 집계 된 데이터를 유지하도록 트리거를 설정할 수 있습니다. 사전 집계없이 응용 프로그램이 허용 할 수 없을 정도로 느린 상황에서만 수행해야합니다.

2004 년의 Atwood의 조언은 오늘날에도 그대로 적용되며 ORM의 혜택도 누릴 수 있습니다.

http://blog.codinghorror.com/who-needs-stored-procedures-anyways/

저장 프로시 저는 가장 성능이 중요한 상황에서만 사용하기위한 데이터베이스 어셈블리 언어로 간주해야합니다. 저장 프로 시저에 의존하지 않고 견고한 고성능 데이터 액세스 계층을 설계하는 방법에는 여러 가지가 있습니다. 매개 변수화 된 SQL과 단일 일관성 개발 환경을 고수하면 많은 이점을 누릴 수 있습니다.

요약 : 저장 프로 시저 사용 및 비즈니스 요구 사항에 따라 다릅니다.

3 계층 아키텍처를 사용하는 많은 프로젝트가 있으며 비즈니스 요구 사항의 특성에 따라 일부 작업을 데이터 계층 으로 이동해야 할 수도 있습니다 .

용어에 대해 말하면 일반적으로 이러한 계층은 다음과 같이 설명됩니다.

• 프리젠 테이션 계층 또는 사용자 서비스 계층-사용자에게 애플리케이션에 대한 액세스 권한을 제공합니다.
• 중간 계층 또는 비즈니스 서비스 계층-비즈니스 및 데이터 규칙으로 구성됩니다.
• 데이터 계층 또는 데이터 서비스 계층-일반적으로 데이터베이스 또는 영구 저장소에 저장된 영구 데이터와 상호 작용합니다.

일반적으로 지정된 아키텍처의 경우 중간 계층 또는 비즈니스 서비스 계층은 비즈니스 및 데이터 규칙으로 구성됩니다. 그러나 때로는 일련의 저장 프로 시저를 통해 대량의 기본 작업 및 / 또는 데이터 규칙을 데이터 계층 에서 수행하도록 변경하는 것이 큰 차이를 만듭니다 .

3 계층 설계의 장점은 다음과 같습니다.

응용 프로그램의 수명주기 동안 3 계층 접근 방식은 재사용 성, 유연성, 관리 용이성, 유지 관리 성 및 확장 성과 같은 이점을 제공합니다. 생성 한 구성 요소와 서비스를 공유하고 재사용 할 수 있으며 필요에 따라 컴퓨터 네트워크에 배포 할 수 있습니다. 크고 복잡한 프로젝트를 더 간단한 프로젝트로 나누고 다른 프로그래머 나 프로그래밍 팀에 할당 할 수 있습니다. 또한 서버에 구성 요소 및 서비스를 배포하여 변경 사항을 처리 할 수 ​​있으며 응용 프로그램의 사용자 기반, 데이터 및 트랜잭션 볼륨이 증가함에 따라이를 다시 배포 할 수 있습니다.

따라서 이는 실제로 자체적으로 절충되는 사례 기반 접근 방식입니다. 그러나 3 계층 아키텍처 모델 의 Microsoft 디자인 지침에서는 비즈니스 로직 을 중간 계층 으로 유지하는 것이 좋습니다 .

계층은 실제로 다른 시스템을 의미하고 계층은 다른 논리적 분리를 의미합니다. 저장 프로 시저를 사용하면 동일한 계층에 데이터 계층과 비즈니스 논리 계층 (적어도 일부)이 있습니다. 비즈니스 로직을 스토어드 프로 시저에 두는 것은 3 단계 아키텍처를 위반하지만 3 계층 아키텍처를 위반하는지 여부는 의문입니다. 한 가지 확실한 점은 그것이 우려의 분리에 대한 좋은 예가 아니라는 것입니다.

계층은 소프트웨어 솔루션을 구성하는 요소에 대한 논리적 구조 메커니즘입니다. 계층은 시스템 인프라를위한 물리적 구조 메커니즘입니다. ( 참조 )

제 생각에는 데이터베이스에서 비즈니스 로직을 구축하는 데 두 가지 주요 문제가 있습니다.

1. 코드 및 라이브러리 : C #, Java 등보다 SQL, PL / SQL, TSQL 등에서 프로그래밍 할 수있는 프로그래머가 적습니다. 프로그래밍 언어에는 뛰어난 IDE, 뛰어난 라이브러리 및 프레임 워크라는 이점이 있습니다.

2. 수평 적 확장 성 : 시스템을 확장 할 수있는 유일한 방법은 데이터베이스가 더 강력한 물리적 서버를 다소 비싸고 (64GB RAM이있는 서버) 변경하는 것입니다. 관계형 데이터베이스는 수평 적으로 매우 나쁘고 더 큰 비용으로 확장됩니다. OO로 구축 된 서버의 비즈니스 로직을 사용하면 서버를 여러 노드에 배치하여 수평 적으로 확장 할 수 있습니다 (Java의 경우 많은 응용 프로그램 서버에서 지원).

우리는 몇 시간 전에 우리 사무실 에서이 토론을했습니다. 나는 데이터베이스 개발을 선호했습니다.

1. Oracle Database를 사용하는 경우 가능한 한 PL / SQL을 최대한 활용해야합니다. 투자하는 회사는 지금부터 최소한 10 년 동안 Oracle에 충실해야하기 때문입니다. 어제 애플리케이션에서 Oracle Forms (오늘 .net 웹 양식, MVC)를 사용하고 있다면 내일에는 angularjs를 사용하고 충분한 API가 필요합니다. 최대 논리가 데이터베이스에 있으면 새로운 프런트 엔드 기술로 쉽게 마이그레이션 할 수 있습니다.
2. 데이터베이스 개발은 매우 빠르고 효율적입니다. 그냥 당신에게 전망을 제공합니다. 우리 프로젝트에는 7 명의 애플리케이션 개발자와 1 명의 데이터베이스 개발자가 있었고 로직의 80 %가 데이터베이스에있었습니다.
3. Oracle을 사용하는 경우 유틸리티를 사용하여 데이터베이스 프로 시저를 Res full Api로 직접 변환 할 수 있습니다.

응용 프로그램 개발자는 비즈니스 로직이 데이터베이스와 독립적이어야하므로 데이터베이스를 쉽게 변경할 수 있다는 가장 강력한 주장입니다. 회사가 Oracle을 사용하는 경우 왜 다른 기술로 전환해야하는지에 대한 대신 응용 프로그램 논리를 사용하지 않을 가능성이 더 높습니다. 문제는 주로 데이터베이스 리소스의 새로운 재능이 부족하다는 것입니다. 대부분의 사람들은 mysql 또는 sqlserver를 사용하는 간단한 웹 사이트를 시작합니다. 이 사람들은 선임 리드가되어 응용 계층과 감정적으로 애착을 갖습니다. :) 심지어 이해하거나 토론하고 싶지도 않습니다.