트랜잭션을 통해 비즈니스 로직을 DB-logic에서 분리

우리는 응용 프로그램에 세 가지 계층이 있습니다. 외부 API를 제공하는 서비스 계층. 비즈니스 로직을위한 BO 계층과 데이터베이스 연결을위한 DAO 계층

파일을 업데이트 할 때마다 '마지막으로 수정 한 날짜'와 같이 폴더에서 무언가를 변경하려고합니다. 이것은 거래에서 이루어져야합니다. 성공하면 파일과 폴더가 모두 편집됩니다. 또는 오류가 발생하여 트랜잭션이 롤백되므로 두 개체가 모두 이전 상태에 있습니다.

"파일을 편집 할 때 폴더 편집"작업은 순수한 비즈니스 논리입니다. 이것은 BO 계층에 속한다는 의미입니다. 그러나 데이터베이스에 Objectify를 사용하므로 트랜잭션을 시작하려면 ofy (). transact (...)를 호출해야합니다. BO 계층에서이 함수를 호출하면 비즈니스 계층에 데이터베이스 특정 호출 (개체화)이 있으므로 설계가 중단됩니다.

이 문제에 대한 깨끗한 해결책은 무엇입니까?

— 헨드릭스 서지
소스

거래 문제로 인해 FileBO전화를 걸 수 없습니까 FolderBO.edit(newDate)?

— 발견

java는 c # TransactionScope와 동일하지 않습니까?

— Ewan

Java에서 트랜잭션 범위는 사용하는 프레임 워크에 따라 다릅니다. JEE에서는 앱 서버에서 관리 할 수 있지만 일반적으로 Spring과 같은 프레임 워크 (vía annotations, xml 등)로 선언적으로 정의하고 관리합니다.

— Laiv

응용 프로그램의 서로 다른 "계층"을 기능적으로 독립적 / 무지하게 만들려고 노력할 필요가 없습니다. 코드가 지원하는 아키텍처를 위해 코드가 작성되었다는 생각을 받아들이고 대신 자체적으로 코드를 작성하는 데 집중하십시오.

— Ant P

답변:

거래를 줄이는 방법은 실제로 비즈니스 논리입니다. 그래서 당신의 DAO 계층은위한 DB 프레임 워크 독립적 인 API 제공 할 수 있도록 transact당신이 언급 한 방법을 (아마 것들에 대한 같은 commit과 rollback). 그런 다음 데이터베이스 나 DB 프레임 워크에 종속되지 않고 BO 계층에서 사용할 수 있습니다.

— 닥 브라운
소스

과 같은 객관화는 원자와 같은 거래 (위해 설계 구글 애플리케이션 엔진 거래 ). 트랜잭션 관리 에 대한 고유 한 추상화를 개발해야합니다 .

이 경우 트랜잭션 관리를 상위 계층 에 어떻게 위임합니까?

@DocBrown 접근 방식은 주어진 아키텍처 ( 계층 구조 ) 에 구현하는 더 빠르고 깨끗한 솔루션을 보여 줍니다.

우리는 응용 프로그램과 해당 컨텍스트에 대한 정보가 너무 많이 누락되어 Doc의 솔루션도 가장 안전합니다.

그러나 비즈니스 계층에 대한 UnitOfWork 디자인 패턴을 살펴볼 것을 제안 합니다. Objectify가 의도 한 트랜잭션 관리에 적합하다고 생각합니다 .

간단히 요약하면이 패턴은 비즈니스 규칙을 비즈니스 트랜잭션 (작업 단위) 으로 캡슐화하는 것을 목표로 합니다. 이 패턴은 B.T 사이의 상속을 허용 하며 지금까지 Objectify 도 볼 수 있습니다. 그것은 심지어 구성을 지원합니다. 따라서 구성 또는 상속에 의해이 접근법은 복잡한 B.T를 허용 합니다.

주어진 아키텍처에 적용하면 다음과 같습니다.

FileService -> FileBO : new EditFileTransaction().execute()
                           |-> ofy().transact(...)
                           |--> FileDAO.actionA()
                           |--> FolderDAO.actionA()
                           |-> [ofy().commit(...)|ofy().rollback()]

— 레이브
소스