비즈니스 로직을 저장 프로 시저에 넣을지 여부

21

"비즈니스 로직을 저장 프로 시저에 넣을지 말지?"라는 주제에 대해 항상 논쟁이 있습니다. ORM 도구를 사용하지 않고 Business Logic을 저장 프로 시저에 넣지 않기로 결정한 경우 Business Logic을 어디에 배치합니까?

이전 응용 프로그램에서는 항상 모든 비즈니스 논리를 저장 프로 시저에만 배치하는 것을 선호했습니다. 그런 다음 .NET 코드에서 데이터 액세스 응용 프로그램 블록을 사용하여 이러한 저장 프로 시저를 호출합니다. SQLHelper 등. 그러나 이것은 항상 시나리오가 될 수는 없습니다. 그래서 나는 인터넷 검색을했지만 혼란에 빠졌습니다 .......

어떤 제안 ...?

c# .net sql

— 프라 빈 파틸
소스

나는 편향되어 있습니다-> 항상 저장된 Procs. 그러나 나는 편견이다. 애자일 프로그래밍은 잊어 버리지 만 슬픈 현실은 비즈니스 세계에서 항상 변경이 발생하며 "즉시"수행되어야한다는 것입니다. 저장 프로 시저를 사용하면 가능합니다. 생명의 은인. 코드베이스를 통해 그러한 변경을 시도하는 것은 불가능합니다.

— Darknight

4

@Darknight, 플랫폼과 아키텍처에 크게 의존하여 이와 같은 진술을합니다. 스토어드 프로 시저를 데이터베이스에 배치하는 것이 빌드 및 배치 스크립트를 실행하여 새 WAR 파일을 빌드하고 배치 한 후 앱 서버를 다시 시작하는 것보다 시간이 덜 걸리는 이유를 모르겠습니다.

— maple_shaft

7

저장 절차-컴퓨터 과학의 정화조.

— Mongus Pong 2013

1

저장 프로 시저-다른 도구와 같은 다른 도구.

— sam yi

15

실용적인 접근 방식을 채택하겠습니다. 역사적으로 비즈니스 로직을 저장된 프로세스에 유지하는 주요 이점은 성능상의 이유로 (2.5 계층 아키텍처), 비즈니스 로직을 BLL 계층 (3 / N 계층)으로 분리하는 것이 일반적으로 유지 관리 관점 및 테스트 용이 (데이터 액세스를 모의 / 스텁 아웃).

그러나 LINQ2SQL, EF 및 NHibernate와 같은 LINQ 지원 .NET ORMS가 이제 매개 변수화 된 SQL 쿼리를 생성하므로 쿼리 계획을 캐시하고 SQL 주입을 위해 이스케이프 처리하는 등 3 / N 계층 아키텍처로의 전환은 그 어느 때보 다 강력 해졌으며 대부분의 SPROC (특히 쿼리 중심)는 피할 수 있습니다. .NET의 리포지토리 패턴은 일반적으로 IQueryable / accept Expression 트리 매개 변수를 노출하므로 형식에 안전하면서도 유연한 테이블 액세스가 가능합니다. (개인적으로 SOA 유형 아키텍처에서는 BLL 이외의 IQueryable을 공개하지 않을 것입니다. 즉, 서비스 및 프리젠 테이션 계층이 잘 정의 된 메소드 세트와 함께 작동해야합니다. 그렇지 않으면 시스템을 완전히 테스트 할 수 없기 때문에 '

그러나 적절한 크기의 시스템에서는 성능상의 이유로 실제로 데이터 집약적 코드 조각을 여전히 Stored Proc로 작성해야하는 몇 가지 예외가 있습니다. 이 경우 SPROC를 유지하고 ORM을 통해 SPROC를 공개하지만 여전히 함수를 BLL에서 통과 메소드로 공개합니다.

— 스튜어트 LC
소스

1

애플리케이션 계층에서보다 쉽게 단위 테스트를 작성하려면 +1을 수행하지만 자동화 된 DB 단위 테스트 프레임 워크는 먼 길을 왔습니다.

— maple_shaft

14

Java 개발자이기 때문에 BLL에 비즈니스 로직을 배치하는 것이 좋았습니다 (좋은 소스 제어, 친숙성 등).

그러나 서로 다른 기술 (C #, Java, Pick (요청하지 않음))을 사용하는 많은 분산 응용 프로그램이있는 대기업에서 근무한 후 저장 프로 시저를 사용하면 얻을 수있는 중요한 이점이 분명해졌습니다.

저장 프로시 저는 다른 응용 프로그램간에 공유 할 수 있습니다 .

— 님심 스키
소스

아주 좋은 지적

— NoChance

1

이것은 매우 사실이며 우리는 환경에 좋은 영향을 미치기 위해 사용합니다. 그러나 데이터 계층을 사용하여 코드를 공유하는 것은 항상 조금 위험 해 보였습니다. 주어진 로직 / 데이터의 소비자가 여러 명인 경우 동일한 데이터베이스의 여러 소비자가있는 것보다 서비스를 선호합니다.

— RationalGeek

2

데이터 관리를 라이브러리로 분할하면 해당 라이브러리를 이론적으로 다른 응용 프로그램에서 공유 할 수 있습니다.

— glenatron

2

동의합니다. 이러한 모든 기술은 데이터베이스에 직접 액세스하고 있습니다. 저장 프로 시저를 사용하여 공통 코드를 공유하고 있습니다. 미들 티어를 보유하고 데이터베이스 대신 미들 티어에 액세스하는 이기종 솔루션을 갖도록하여 동일한 문제를 해결할 수 있으며, 해당 미들 티어는 이러한 코드를 공유합니다.

— Ekevoo 2019

1

이 답은 6 년 후에도 헛소리입니다. 데이터 만 데이터베이스에 저장됩니다. 거기에 논리를 넣으면 많은 문제가 발생합니다. 원하는 언어로 DB에 액세스하는 마이크로 서비스를 구축하십시오.

— NimChimpsky 2016 년

6

우리 팀은 여기에 부드러운 규칙이 있습니다. 때로는 T-SQL에서 비즈니스 로직을 해결하는 것이 좋으며 c # (비즈니스 계층)에서 수행하는 것이 더 쉽습니다.

실용적인 해결책이 있습니다. 나는 이론이 때로는 그것에 대해 매우 엄격하다는 것을 알고 있습니다 ... 그러나 그것은 이론입니다 :-)

— gsharp
소스

2

확실히 이것이 모두의 최악의 해결책입니까? 유지 보수 개발자는 로직이 저장된 위치를 어떻게 알 수 있습니까? 때로는 응용 프로그램 계층이나 UI가 더 나빠지는 경우가 있다고 생각합니까?

— Paul T Davies

2

아니. 항상 비즈니스 계층 또는 T-SQL에 있습니다. 로직이 어디에 저장되어 있는지 파악하는 것이 유지 보수에있어 가장 작은 문제 일 것입니다.

— gsharp

누군가가 팀에 합류하여이 규칙을 말하면 어떻게됩니까? 그들은 "어떤 것이 더 잘 맞는지"어떻게 알 수 있습니까? 이것은 거의 규칙이 아닌 것 같습니다. 개인에 따라 매우 주관적입니다.

— RationalGeek

3

얘들 아, 진심이야? 우리는 생각하고 기내 경험이있는 두뇌를 가진 사람들을 고용합니다. 그럼 .. 오, 그들은 물어보고 대화 할 입이 있어요. 우리의 소프트웨어는 유지 보수가 매우 적고 팀의 거의 모든 사람이 새로운 기능을 잘 구현할 수 있다고 말할 수 있습니다. 우리가하는 일이 잘못 될 수는 없습니다.

— gsharp

4

SQL Server가 훨씬 더 잘 할 수있는 일에 대해 C #을 잘못 사용하는 것이 의미가 없으며 그 반대도 마찬가지입니다.

— gsharp

3

(제 생각에) 두 가지 장점과 단점이 있습니다.

저장 프로시 저는 일종의 SQL 소스 제어를 사용하지 않고 (많은 장소에서 사용하지 않는) 여러 개발자가 작업하는 경우 악몽이 될 수 있습니다. 누군가 저장 프로 시저를 변경하고 해당 프로 시저를 호출하는 코드를 업데이트하는 것을 잊어 버릴 수 있으며이를 알기 전에 처리되지 않은 예외 (매개 변수 수 불일치 등)를 발생시키는 사이트를 구축하고 배포했습니다.

반면에 저장 프로시 저는 특정 상황에서 더 빠른 버그 수정을 허용합니다. 저장 프로 시저에 버그가있는 경우이를 수정하면됩니다. ORM의 버그 수정에는 재구성이 필요합니다. 빌드 프로세스에 따라 시간이 오래 걸리고 성 가실 수 있습니다.

— AndrewC
소스

저장된 procs를 많이 사용하려는 경우 저장된 procs로 소스를 제어해야 할 경우 +1하십시오. 내가 함께 일한 많은 DBA는이 아이디어에 매우 강하다.

— RationalGeek

2

우리는 항상 비즈니스 로직을 비즈니스 로직 레이어에 넣습니다. 저장 프로시 듀어에 넣으면 RDBMS를 변경하면 손실됩니다.

— 슐 리커
소스

16

마지막으로 바뀌는 것은 RDBMS입니다. ;-)

— gsharp

따라서 저장 프로 시저를 데이터 페치, 업데이트 및 삽입으로 제한한다는 의미입니까?

— Pravin Patil

1

내가 본 모든 큰 시스템에서 현실은 데이터베이스가 시스템이라는 것입니다. 이 시점에서 프로그래밍 언어는 "프론트 엔드"와 거의 관련이 없습니다.

— Darknight

2

@gsharp, 항상 그런 것은 아닙니다. Oracle과 같은 다른 RDBMS를 추가하거나 기존 RDBMS를 완전히 대체 할 수 있습니다. 또는 실제 데이터를 더미 데이터로 바꾸려는 경우도 있습니다.

— šljaker

2

물론 @ šljaker 항상 그런 것은 아닙니다. 그러나 DB 대신 프로그램이 변경 될 가능성이 높습니다 (소프트웨어의 재 설계, 새로운 프로그래밍 언어 등).

— gsharp

2

"비즈니스 로직"은 약간 모호한 용어입니다. 단일 정의가 없다는 의미입니다. 경험상 가능한 계층 간의 통신을 최소화하는 것이 좋습니다. 따라서 행을 삽입하기 전에 빈 고객 이름을 서버로 보내서 확인할 필요가 없습니다.

규칙이 데이터베이스 읽기를 기반으로하는 경우가 있습니다. 계정 1에서 계정 2로 돈을 이체한다고 가정합니다. 두 계정을 모두 읽고 상태가 양호하고 계정 1의 금액이 충분한 지 확인해야합니다. 이 경우 클라이언트 (여기서는 BL 임)가이 프로세스를 위해 데이터베이스 계층에 대해 3 번의 호출을 실행할 필요가 없기 때문에 서버는이 규칙에 더 적합한 후보입니다.

물론, 데이터베이스에 독립적 인 솔루션이 필요한 경우 CRUD에 대해서만 저장 프로 시저를 작성하십시오 (사용 된 경우).

— 기회 없음
소스

1

논리는 항상 다음과 같은 이유로 BLL에 있어야합니다.

제대로 테스트 할 수 있습니다
SQL 20XX가 더 이상 사용되지 않고 최신 버전으로 변경해야하는 경우 코드를 다시 작성할 필요가 없습니다.
사람들은 즉시 변경하려고 유혹하지 않습니다 (SP에 대한 논쟁으로 제시되고있는 것 같습니다)
내 경험상 SP는 특히 몇 세대의 유지 관리 / 변경 후 개발자 오류의 가장 큰 지점입니다.

SP가 X 줄보다 길면 의도 한대로 작동하지 않는다는 법률이 있어야한다고 생각합니다.

— 폴 T 데이비스
소스

변경 사항이 무엇입니까? 저장 프로 시저에 버그가 있고 쉽게 수정되면 수정하십시오. 그것은 사소한 일에 대해 다시 릴리스 할 필요가 없다는 것을 의미하기 때문에 긍정적입니다. 사람들이 저장 프로 시저를 변경하여 코드에서 버그 마스킹을 시작하지 않는 한 아무런 문제가 없습니다.

— AndrewC

즉석에서 변경함으로써 테스트되지 않았으며 공식 릴리스 절차를 따르지 않는 것을 의미합니다. 그리고 예, 마스크 코드 버그에 대한 sp 변경은 내가 본 것 중 일부입니다.

— Paul T Davies

0

우리는 선택된 언어로 구현 된 모든 비즈니스 로직을 포함하는 서비스 계층을 생성하고 쿼리에 데이터베이스 만 사용합니다. 우리의 목표는 다양한 데이터베이스 구현으로 응용 프로그램을 제공하기 위해 COTS 솔루션을 만드는 것이기 때문에 이러한 접근 방식은 우리가 위임 한 것입니다. 이러한 상황에서 최대 절전 모드는 생명의 은인으로 입증되었습니다.

데이터베이스 이식 성과는 별도로이 방법의 가장 큰 장점은 한 번의 검색으로 모든 답변을 찾을 수 있다는 것입니다.

또한 포럼에 대한 답변 중 일부에도 불구하고 회사에서 선택한 데이터베이스가 변경되어 3 년 동안 2 개의 데이터베이스 변환을 수행 한 100 대 보험 회사에서 일하는 친구가 있습니다.

— 톰
소스

0

제한된 경험에서는 저장 프로 시저 및 기타 데이터베이스 기능으로 데이터 무결성을 유지하는 것을 선호합니다. 예를 들어 두 계정간에 자금 이체를 구현하는 경우 저장 프로 시저를 작성합니다. 여러 응용 프로그램 언어를 사용할 수 있다는 것이 중요합니다.

— 케빈 클라인
소스