이전 블로그에서 우리는 프론트엔드 컨트롤러, 페이지 컨트롤러, 애플리케이션 컨트롤러의 세 가지 프리젠테이션 레이어 모드에 대해 배웠습니다. 시스템 내부, 비즈니스 로직 계층의 작업은 애플리케이션의 비즈니스 부분을 처리하는 것입니다. 비즈니스 로직 계층은 외부 "노이즈"로부터 멀리 떨어져 있어야 합니다. 비즈니스 로직은 전체 애플리케이션의 기본 목적이며 시스템의 다른 부분이 이 부분을 담당합니다.
다음은 일반적으로 사용되는 두 가지 도메인 로직 패턴, 즉 트랜잭션 스크립트 패턴과 도메인 모델 패턴입니다.
1. 트랜잭션 스크립트
1.1 개념
트랜잭션 스크립트: 프로세스를 사용하여 비즈니스 로직을 구성하고 각 프로세스는 프레젠테이션의 단일 요청을 처리합니다. 층 . 좀 너무 추상적인 것 같습니다. 대부분의 비즈니스 애플리케이션은 일련의 트랜잭션으로 볼 수 있습니다. 때로는 트랜잭션이 단순히 데이터베이스 정보를 표시할 수도 있고 때로는 많은 체크섬 계산 단계가 포함될 수도 있습니다. 트랜잭션 스크립트는 이 모든 논리를 단일 프로세스로 구성하고 각 트랜잭션에는 자체 트랜잭션 스크립트가 있습니다. 즉, 트랜잭션 간의 공통 하위 작업이 여러 하위 루틴으로 분해될 수 있습니다.
1.2 트랜잭션 스크립트를 사용하는 이유
트랜잭션 스크립트 모드의 장점은 원하는 결과를 빠르게 얻을 수 있다는 것입니다. 각 스크립트는 입력 데이터를 잘 처리하고 데이터베이스를 조작하여 원하는 결과를 보장합니다. 따라서 복잡한 설계에 많은 시간과 노력이 필요하지 않은 빠르고 효과적인 메커니즘으로 마감 기한이 촉박한 소규모 프로젝트에 적합합니다.
1.3 트랜잭션 스크립트 구현
저의 업무 경험에 따르면 이전에 저를 포함해 많은 프로그래머들이 이 모델을 모르고 사용하고 있습니다.
이제 블로그를 게시하고 블로그를 삭제하는 비즈니스가 있다고 가정하고, 이 두 비즈니스를 각각 두 개의 트랜잭션 스크립트로 처리합니다.
PHP 코드
- //pdo를 가정하여 여기에 데이터 처리를 위한 기본 클래스를 생성합니다
- 추상 클래스 기본 { 🎜>
- ~ > > 예외(
"DSN 없음"- ) } 🎜>
-
self::$DB = new PDO($dsn
); - self::$DB->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_예외); 🎜>
} -
보호 함수
doStatement() { 🎜>-
//sql 실행-
- } }
-
class blogManager extend Base {
-
static- $add_blog =
"INSERT INTO 블로그(이름) 값(?)"- static
$del_blog- = "블로그에서 삭제(?)" //
블로그- 추가 트랜잭션 스크립트
-
function
addBlog(...) { -
- //매개변수 처리, sql 철자법 add_blog 형식, 부모 클래스 doStatement를 호출하여 실행하고 친구에게 알리는 일련의 서브루틴. . . 트랜잭션 스크립트
- 기능 delBlog(...) {
- / /Process 매개변수, sql을 del_blog 형식으로 철자하고 상위 클래스 doStatement를 호출하여 실행합니다. }
} ?> - 이 예는 매우 간단하지만 바로 그 단순성 때문에 트랜잭션 스크립트의 장점을 반영합니다. 더 복잡한 애플리케이션을 작성하는 경우 트랜잭션 스크립트가 필연적으로 서로 블리딩되어 코드 중복이 발생하므로 이 접근 방식을 사용하면 프로젝트의 확장성이 떨어집니다. 2. 도메인 모델 2.1 개념
- 도메인 모델: 말로는 명확하게 설명하기 어렵습니다. 간단히 말해서, 도메인 모델은 현실 세계에서 프로젝트에 참여하는 다양한 참가자를 상징합니다. "모든 것은 객체"라는 원칙이 여기에 가장 생생하게 반영됩니다. 다른 곳에서는 객체 가 항상 다양한 특정 책임을 수행하지만 도메인 패턴에서는 속성 집합과 연결된 에이전트로 설명되는 경우가 많습니다. 그것들은 특정한 일을 하는 특정한 것들입니다.
- 2.2 도메인 모델을 사용하는 이유 실제 코드에는 많은 트랜잭션 스크립트 패턴이 있으며 중복 코드가 일반적인 문제라는 것을 알게 될 것입니다. 서로 다른 트랜잭션이 동일한 작업을 수행하려는 경우 복제가 가장 빠른 솔루션인 것처럼 보이지만 이로 인해 코드 유지 관리 비용이 크게 증가합니다. 때로는 리팩토링으로 해결될 수도 있지만 천천히 복사 붙여넣기가 개발에서 피할 수 없는 부분이 될 수도 있습니다.
2.3 도메인 모델 구현
비교를 위해 트랜잭션 모델의 예를 인용하고 도메인 모델 클래스를 관계형 데이터베이스의 테이블에 직접 매핑합니다. (이렇게 하면 개발이 더 쉬워집니다.)
PHP 코드
- //pdo를 가정하여 여기에 데이터 처리를 위한 기본 클래스를 생성합니다
- 추상 클래스 기본 { 🎜>
- > getDSN( ) 🎜>$dsn
) ) { - DSN" );
- } $DB = new
PDO( - $dsn ); > self::$DB-> ;setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_예외) 🎜>
- protected function doStatement() { //sql 실행
- }
- }
-
class blogModel 확장
기본{ - 함수 addBlog(...){}
- }
-
- //도메인 모델의 기본 클래스 생성
- 추상 클래스 도메인 개체 {
-
비공개
- $id
-
//$id는 테이블 데이터의 기본 키 ID입니다
-
function __construct( $id
-
function getId() {
-
return- $this->id;
- }
- //모든 것이 객체
- 라는 점을 기억하세요. 정적
함수- getCollection( $type ) {
- //작업할 객체 가져오기
- } }
-
class 블로그
extend- DomainObject {
- private $name;
- > $피드
-
> =null, - $name=null ) {
- $this->name = $name; 🎜>
- $this->feed = self::getCollection("\woo\domain\Feed"); parent::__construct(
$id- ) }
-
- 기능 addBlog(...){
- //blogModel 메소드를 호출하여
-
🎜 >
$this- ->feed 추가 = $피드;
- }
?> 🎜>-
2.4 요약도메인 모델은 단순하게 설계되었으며 비즈니스 로직의 복잡성에 따라 다릅니다. 도메인 모델을 사용하면 모델을 설계할 때 시스템이 해결하려는 문제에 집중할 수 있고 다른 문제(예: 지속성, 성능 등)는 다른 계층에서 해결할 수 있다는 장점이 있습니다. 구현 프로젝트에서 대부분의 프로그래머는 여전히 도메인 모델을 설계할 때 절반의 관심을 데이터베이스에 집중합니다. 데이터 계층에서 도메인 모델을 분리하는 데는 비용이 들며 데이터베이스 코드를 모델에 직접 넣을 수도 있습니다(실제 SQL을 처리하기 위해 데이터 항목을 사용할 수도 있음). 상대적으로 단순한 모델의 경우, 특히 클래스가 데이터 테이블과 일대일로 대응하는 경우 이 방법은 완전히 실행 가능하며
객체 - 및 데이터베이스를 조정하기 위한 외부 시스템을 만드는 데 소요되는 시간을 줄일 수 있습니다.
위의 내용을 포함하여 비즈니스 로직 레이어의 트랜잭션 스크립트와 도메인 모델을 소개합니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.