비즈니스 로직, AppLayer, DataLayer를 어디에 둘 것인지?

Question

이 게시물을 읽은 후에 (business logic database or application layer) "데이터베이스의 비즈니스 로직"주제와 여전히 싸울 충분한 이유가 없습니다.

내 현재의 작업에는 많은 DB 트랜잭션 (실제로)이 있고 그 진절머리가 나는 코드는 저장하기 어렵다. 스토어드 프로 시저에서 많은 복제가 발생하므로, 테이블의 값을 변경하려면 조금이라도, 당신은 그 모든 절차를 찾아 당신이 원하는 것으로 바꿀 필요가있을 것입니다. 테이블 디자인을 약간 변경해야하는 경우에도 마찬가지입니다.

현재 모든 개발자는 SQL을 잘 알고 있지만 데이터베이스 (Dvista)의 전문가는 아닙니다 (8 devs).

현재 전체 코어를 새 버전 (데이터베이스 디자인 포함)으로 마이그레이션 할 계획입니다.

• 왜 비즈니스 로직은 데이터베이스에 때로는 악 : 그리고 일부 예이 필요하십니까?
• 데이터베이스의 비즈니스 로직이 얼마나 좋은지 언제입니까?
• 왜 응용 프로그램 계층의 비즈니스 논리가 엔터프라이즈 응용 프로그램에 적합한 지 알아보십시오.?

응용 프로그램 언어 : 자바
데이터베이스 : Oracle11g
서비스를해야합니다 응용 프로그램은, HTTP 페이지로 및 웹 서비스 역임했습니다.

Answer 1

진부한 코드는 실제로 유지하기 어렵습니다. 그것이 진부한 코드의 특성입니다 - 그것이 위치한 곳이 아닙니다. 프런트 엔드 솔루션에서 "진절머리가 난 코드"로 옮기는 것은 실제로 솔루션이 아닙니다.

그리고 데이터베이스 구조 변경이 프론트 엔드에 코딩 된 비즈니스 로직에 영향을 미치지 않는다면 ... ummm 논리는 다르게 지정합니다.

저는 프론트 엔드에서 잘 처리되고, 백 엔드에서 처리되는 것이 더 좋다고 생각합니다. 그리고 비즈니스 오브젝트 레벨에서 작동하는 적절한 PL/SQL API 디자인이 구조 변경 문제를 다른 레이어와 분리하여 완화 할 수 있다고 생각합니다.

그러나 다른 DB를 지원할 생각이 있다면 모든 DB가 동일한 구문을 지원하지는 않으므로 문제가되는 아이디어이기도합니다.

비즈니스 논리가 어디에 속하는가는 애플리케이션에 전적으로 의존 할 수 있으며, 실제로 성능상의 이유로 여러 계층에서 특정 측면을 갖는 것이 유리할 수 있습니다. 물론 이것은 유지 관리 문제를 야기 할 수 있지만 이것 모두는 프로젝트 나 제품을 전달하는 데 필요한 절충안의 일부가됩니다.

그러나 하나의 엄격한 보편적 인 대답은 확실하지 않습니다.

Answer 2

다른 데이터베이스 브랜드로 마이그레이션 할 수있게하려면 비즈니스 논리를 저장 프로 시저에 포함하지 않아야합니다.

복잡한 도메인의 경우 도메인을 모델링하는 것이 OO 모델을 사용하는 자바 측에서 DB 측보다 훨씬 더 자연 스럽습니다. 객체 지향은 그들 사이의 추상화와 관계를 표현하는 데 적합하다.

주제에 대한 표준 도서는 Domain Driven Design입니다.

DB쪽에 머물러야하는 이유는 성능 일 수 있습니다. 개의 비즈니스 데이터가있는 경우 애플리케이션에서 검색하고 조작하기에 충분하지 않을 수 있습니다. 이는 일괄 처리에 특히 해당됩니다.

Answer 3

AskTom 스레드를 읽었습니까? J2EE and Oracle's stored procedures

Business Logic - PL/SQL Vs Java - Reg

Application design - logic in Database vs logic in Web (Application) server

• 그들은 좋은 읽기와 톰 카이트에서 큰 지혜를 가득합니다. 유일한 문제는 그들이 원하는 답변을지지하지 않는다는 것입니다. 반대 의견을지지합니다!

Answer 4

데이터베이스에 비즈니스 로직의 문제는 확장 할

• 비싸다.당신은 오라클을 사용하고 있습니다. 따라서 오라클을 실행하는 또 다른 16 코어 박스를 추가하는 데 드는 비용은 얼마입니까?
• DB 공급 업체에 국한되어 있습니다 (기술 현명한 경우에도 코드를 마이그레이션 할 수 없음).

장점은

• 원 스톱 상점입니다 : 모든 DB 클라이언트는 같은 논리를 실행합니다. 여러 개의 인터페이스가 있다면 모두 같은 로직을 사용할 수 있습니다.

저는 DB에있는 모든 논리를 가진 보험 회사에서 일했지만 그 이상 이었지만 매우 비쌌습니다. 저는 여러분의 질문에 대한 답이 매우 추상적이라고 생각합니다. 이와 같은 큰 건축 결정을 내릴 때 고려해야 할 많은 점들이 있습니다.

Answer 5

데이터 계층의 비즈니스 로직은 일반적으로 악의적 인 것으로 인식되는데, 몇 가지 이유 때문에 일반적인 것에 집중하려고합니다.

1. 당신은 깨끗하게 단위 테스트를 수행 할 수 없습니다 단위 테스트의 일반적인 아이디어

   하나는뿐만 아니라 문제가 당신에게,하지만 문제는 여기서 또한 알 것입니다. BL이 데이터 계층에 있고 BL 테스트가 작동하지 않는 경우 문제가 논리 또는 데이터에 있는지 확인할 수 없습니다. 따라서 디버그 시간이 길어집니다.

2. 스텁 전체 층 조롱 : 전체 층 스텁 될 적층 구조를 갖는 주요 장점

   하나. 따라서 스텁 DAO 레이어를 사용하는 동안 로직을 별도로 개발할 수 있습니다 (별도의 팀에서 개발할 수 있음). 따라서 데이터를 어디에서 어떻게 얻을 수 있는지 걱정하지 않아도됩니다. 따라서 도메인 모델이 아직 완성되지 않았더라도 논리를 자유롭게 개발할 수 있습니다.

3. 계층 :

   레이어에 깔끔하게의 많은 (! 대) 쉽게 그들이 (예를 들어 다른 서버에) 별도의 물리적 인스턴스에서 작동하도록 분리합니다. 따라서 예를 들어 데이터 영역을 확장 할 수있는 여러 서버를 가질 수 있습니다 (AFAIK는 흔하지 않습니다). 분명히 당신의 논리가 있다면 그것은 훨씬 더 어려울 것입니다 (가능하다면).

Answer 6

왜 데이터베이스의 비즈니스 로직이 악의적 인 이유는 무엇입니까? 한 공급 업체의 지원을 다른 공급 업체로 이동하려면 각 공급 업체의 각 업데이트를 수행해야합니다. 게시물 중 하나에서 언급 한 비싼.

데이터베이스의 비즈니스 로직은 얼마나 좋은가? 비즈니스 논리와 관련이없는 저장 프로 시저를 통해 외래 키나 관련 행을 업데이트하거나 삭제하는 논리가 좋습니다.

응용 프로그램 계층의 비즈니스 논리가 엔터프라이즈 응용 프로그램에 적합한 이유는 무엇입니까? ? 유지 관리가 쉽기 때문에 응용 프로그램 계층은 휠을 다시 발명하지 않으려면 막대한 노력과 비용을 절약 할 수있는 프레임 워크를 활용할 수 있습니다. 응용 프로그램 계층에 사용되는 스레딩 또는 언어 별 전원 사용.

Answer 7

- 왜 데이터베이스의 비즈니스 로직이 악의적 인 이유는 무엇입니까?

1. DB를 사용하는 경우 로깅을 구현하는 방법은 무엇입니까? 당신이 DB에 로그인하고 있다고 말하지 마라. :)
2. 확장하기 힘듭니다.
3. 일반적으로 데이터베이스 스크립트는 읽기가 더 어렵습니다.
4. 테스트하고 조롱하기가 더 어렵습니다.
5. 데이터베이스를 변경해야한다면 어떻게해야합니까? 예를 들어, 귀사에서 Oracle 라이센스를 구입할 수 없게되어 다른 데이터베이스로 변경해야합니다. 마이그레이션은 큰 문제가 될 것입니다.

- 얼마나 많은 경우 비즈니스 로직 데이터베이스가 좋은 방법입니까?

가능한 한 최소. 나는 응용 프로그램의 구현이 심각한 데이터베이스 성능에 영향을 미칠 때만 사용했다. 이런 이유 때문에 PL/SQL에서 더 나은 선택이 될 수 있습니다.

- 응용 프로그램 계층의 비즈니스 논리가 엔터프라이즈 응용 프로그램에 더 적합한 이유는 무엇입니까? ?

답변은 첫 번째 답변과 동일합니다.

Answer 8

그것은 수도있을 가난한 디자인 선택 (EVIL되지 않음) 여러 데이터베이스가

당신은

당신은 다른 데이터베이스 버전

을 지원하는 데 필요한 다른 데이터베이스 버전을 지원해야하는 벤더 지원해야

1. 경우
2. 비 데이터베이스 계층에 논리를 추가하면 데이터베이스 서버의 CPU로드가 감소하고 관련 라이센스 비용이 절감된다는 사실을 알 수 있습니다.논리를 비 데이터베이스 계층에 추가하면 더 많은 데이터베이스 요청, 더 많은 네트워크 트래픽, 더 많은 데이터베이스 세션 사용, 데이터 캐싱 중복 등이 발생하여 실제로 데이터베이스 계층에로드를 추가하고 아무것도 저장하지 않는다는 것을 알 수 있습니다 .
3. 기존 스킬 셋의 오용. 전체 직원이 Java에 능숙하다면 PL/SQL (또는 Ruby 또는 .Net)에서 새 응용 프로그램을 개발할 때 약간의 요점이 있습니다. 마찬가지로 직원이 PL/SQL 기술을 보유하고 있다면 Java로 재 구축하는 데 많은 비용이 듭니다.
4. 금형의 부족 또는 비용. 오라클을위한 테스트 프레임 워크가 있지만, 퀘스트와 같은 상업용 프레임 워크는 오픈 소스보다 낫습니다.