Laravel 5의 웨어하우징 모드

저장소 패턴은 Eric Evans가 자신의 Domain-Driven Design 책에서 처음 소개했습니다. 실제로 저장소는 applications가 domain레이어에 액세스하는 진입점입니다.

간단히 말하면 저장소를 사용하면 개체가 어떻게 유지되는지 알지 못해도 모든 코드에서 개체를 사용할 수 있습니다. 리포지토리에는 테이블에서 개체로의 매핑을 포함하여 지속성에 대한 모든 지식이 포함되어 있습니다. 이는 지속성 계층에 대한 보다 객체 지향적인 보기를 제공하고 매핑 코드를 보다 캡슐화합니다.

Laravel에서 저장소를 작동하게 만드는 유일한 방법(실제 저장소 - Eric Evans Domain Driven Design 책)은 기본 ORM을 Active Record에서 Data Mapper로 변경하는 것입니다. 가장 좋은 대체물은 교리이다.

교리 ORM

Doctrine은 데이터 매퍼 패턴을 구현하고 애플리케이션의 비즈니스 규칙을 데이터베이스의 지속성 계층에서 완전히 분리할 수 있게 해주는 ORM(객체 관계형 매핑)입니다. Doctrine은 SQL이 아닌 DQL을 사용합니다. DQL은 개체 쿼리 언어를 제공합니다. 즉, 기존 관계형 쿼리 용어 대신 개체 용어를 사용하여 쿼리하게 됩니다.

객체 지향 방식으로 데이터베이스 쿼리를 작성할 수 있으며 기본 저장소 방법으로는 불가능한 방식으로 데이터베이스를 쿼리해야 할 때 도움이 됩니다. 제 생각에는 DQL은 데이터베이스에 대한 연결을 유지하는 가장 강력한 방법입니다.

교리와 웅변

Doctrine 엔터티는 ORM 상속 오버헤드를 추가하지 않는 일반적인 PHP 단순 클래스입니다. Doctrine은 동일한 상속을 사용하여 데이터베이스에 액세스하지 않고 여러 쿼리 요청을 관리합니다. 이는 요청 전체에 엔터티 객체가 존재함을 의미합니다.

Doctrine의 또 다른 멋진 기능은 데이터베이스 스키마를 생성하기 위해 파일을 마이그레이션하는 대신 엔터티 주석의 메타데이터를 반영하기 위해 데이터베이스가 자동으로 생성된다는 것입니다. 반면에 Eloquent는 덜 복잡하고 사용하기 매우 쉽습니다.

이 두 가지를 완전히 비교하려면 별도의 기사가 필요합니다. 보시다시피 Doctrine 개체는 더 가볍고 추상적입니다. 그러나 Doctrine은 특정 프로젝트에만 적합하므로 때로는 오버헤드가 발생할 수 있습니다. 나는 애플리케이션에 가장 적합한 ORM을 선택하는 것은 프로그래머의 몫이라고 믿습니다.

블로그 앱

이제 Laravel을 사용하여 블로그 애플리케이션을 만들 차례입니다. 먼저 교리를 세워야 합니다. Laravel 5의 기존 구성과 일치하는 브리지가 있습니다. Laravel 프로젝트에 Doctrine 2를 설치하려면 다음 명령을 실행합니다:

으아아아

평소처럼 서비스 제공자로서 패키지를 app/config.php 에 추가해야 합니다.

으아아아

별칭도 구성해야 합니다.

으아아아

마지막으로 패키지 구성을 게시합니다.

으아아아

이제 끝났습니다.

엔티티는 애플리케이션의 중요한 부분입니다. AppEntitiesPost.php:

으아아아

이제 앞서 설명한 repository를 생성할 차례입니다. App/Repositories/PostRepo.php :

으아아아

컨트롤러:App/Http/Controllers/PostController.php :

으아아아

보시다시피 저는 Flash Assistant를 사용하여 메시지를 관리합니다(Laravel을 사용할 수 있습니다). 유효성 검사기와 관련하여 선호도에 따라 직접 만들거나(저처럼) Laravel 기본값을 사용할 수 있다는 점을 덧붙이고 싶습니다.

평소처럼 파일을 봅니다. 이 예시 보기에서 파일은 다음과 같습니다. resources/views/admin/edit.blade.php :

으으으으

위 내용은 Laravel 5의 웨어하우징 모드의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!