Laravel 모델 클래스를 어디에 배치할지 고민
이 문장에 관하여
Laravel Advent Calender 2019 다음날 보도.
Laravel에서 모델 클래스의 위치를 확정하지 않았습니다. 기본적으로 만들어진 사용자 클래스는 앱 바로 아래에 있습니다.그럼에도 불구하고 모든 모델 클래스를 앱 바로 아래에 놓으면 트리 보기에서 볼 수 있는 가시성이 떨어지기 때문에 가능하다면 캐릭터와 상하문에 따라 설정을 분할하고 싶습니다.
지금까지 저는 10개에 가까운 Laravel을 사용하는 응용 프로그램에 참여하여 다양한 구성을 보았지만 최근에는 수렴이 하나의 형식으로 되었다는 인상을 받았기 때문에 문제를 제기하면서 다양한 모델의 장단점을 고찰했습니다.어떤 설정을 탐색해 보려는 시도입니다.
------2019-10-0812:36 추기------
"4. 응용 프로그램에 독립된 Domain"의 구체적인 구성, 장단점에 대해 @kazuhei 씨가 이 글에서 언급했으니 함께 읽어 주십시오.
Laravel이 만든 응용 프로그램과 도메인을 독립적으로 만드는 모드 - Qiita
여기까지.
입문
환경
모델/모델 정의
이 글에서'모델'(알파벳으로 표시)은 Eloquent Model을 가리키고,'모델'(영화 가명으로 표시)은 개념적인 것을 가리킨다.본 보도에서 보기와 컨트롤러를 제외하고 모두 모델로 처리한다.
패턴 목록
초기 구성
필요하면 디렉터리를 만들 수 있기 때문에 초기 상태가 시원합니다.
$ tree -L 1 app
app
├── Console
├── Exceptions
├── Http
├── Providers
└── User.php
모드 1: 기본
앞에서 말한 바와 같이 앱 바로 아래에 놓인 모드입니다.
배포 예
tree -L 1 app
app
├── Console
├── Customer.php
├── Deliverer.php
├── Exceptions
├── Http
├── Order.php
├── Providers
└── User.php
이점
php artisan make:model Hoge 및 실행 시 app/Hoge.php.장점은 최소한의 유형수로 만들 수 있다는 것이다.결점
앞에서 말한 바와 같이 트리 보기에서 볼 때 모델의 파일은 한 줄로 배열되기 때문에 시각적 식별성이 떨어진다.
느끼다
그 중에서 트리 보기를 보지 않거나 시각적 식별성이 떨어지는 것을 개의치 않는 사람이 있을지도 모르지만 저는 불가능합니다. 그래서 몇 개의 파일로 프로그램을 구성하지 않았다면 이 모드를 선택하지 않았을 것입니다.
모델 2: 모델
app/Models 아래 모드에 배치합니다.
라벨 4 시대에는 모델 목록이 있었지만 5가 되면 없어졌다.4시대부터 접했는데 그게 익숙해져서 잃어버렸을 때 에이, 왜 잃어버렸어?내 생각엔
배포 예
$ tree -L 2 -d app
app
├── Console
├── Exceptions
├── Http
│ ├── Controllers
│ └── Middleware
├── Models
│ ├── Base
│ ├── Delivery
│ └── Order
└── Providers
이점
모델 3에 비해 이 모델은 역할에 따라 구분하지 않고 상하문이나 집합 루트에 따라 구분하기 쉽다.
주문 및 배송 컨텍스트가 있는 경우 다음 방법으로 각 컨텍스트별로 배포할 수 있습니다.또한 각 컨텍스트에서 Enties, Services 등을 작성할 수도 있습니다.
결점
이것도 모델 3과 비교된다. 그러나 상하문이 하나 또는 그렇게 많지 않고 모든 상하문의 행위가 변화하지 않는 상황에서 계층만 증가하면 아무런 의미가 없을 수 있다.
느끼다
지금 이게 제일 잘 어울려요.모델 (예를 들어 Policy와 Observer) 과 밀접한 관계를 가진 클래스를 어디에 두어야 할지 (기본값인지 모델스 이하인지) 고민스러운 부분이지만, 지금 기본값이 좋다고 생각합니다.
모델 3: 실체, 값 대상, 서비스 등
모델 형식(예를 들어 app/enties, app/Services)에 따라 디렉터리를 자르는 모드입니다.요즘 이런 패턴을 자주 만나요.
배포 예
$ tree -L 2 -d app
app
├── Console
├── Entities
│ ├── Deliver
│ └── Order
├── Exceptions
├── Http
│ ├── Controllers
│ └── Middleware
├── Providers
├── Services
│ ├── Deliver
│ └── Order
└── ValueObjects
├── Deliver
└── Order
이점
패턴 2와 비교하지만 상하문별로 분리하려면 종류별 디렉터리에서 분할됩니다.결과적으로 모든 종류의 디렉터리 아래에는 각자의 디렉터리가 있는데 상하문이 하나 적거나 극히 적으면 가장 간단한 구성일 수 있다.
결점
평소에 이렇게 하면 나쁘다고 생각하지 않지만 억지로 열거하면 클래스의 종류에 끌릴 수 있고 관련된 강류는 분할된다. 실제 상황은 값 대상이 아닌데 Value Objects에서 혼란스럽다.
느끼다
모드2를 선택하느냐, 3을 선택하느냐 극적으로는 좋아하는 문제다.저는 개인적으로 모델의 종류(실체인지 서비스인지)를 별로 신경 쓰지 않습니다. 아무래도 어떤 상하문의 종류(대상)에 의식이 있기 때문에 모델 2를 추천합니다. 하지만 팀에서 잘 상의해서 결정하면 될 것 같습니다.
모드 4: 응용 프로그램에 독립된 도메인
최근에 열렬한 역구동 디자인성, 청결 구조성, 프레임에 대한 의존성 제로, 또는 이런 전략을 극력 줄이는 토대에서 만들어진 디렉터리 구성이다.
저는 이런 방침으로 라벨을 채택하는 프로젝트에 참여한 적이 없습니다. 사소한 장단점은 상상의 범위 내에서만 알 수 있기 때문에 설정례만 기재합니다.실제로 채용된 사람이 있다면 댓글로 장단점을 알려주면 좋겠다.
실시의 상세한 상황은 이 문장을 참고할 수 있다.
독립 코어 레이어 어레이 - Shin x Blog
배포 예
$ tree -L 2 -d ./app ./domain
./app
├── Console
├── Exceptions
├── Http
│ ├── Controllers
│ └── Middleware
├── Infrastructure
│ └── Repositories
└── Providers
./domain
├── Delivery
│ ├── Entities
│ └── Repositories
└── Order
├── Entities
└── Repositories
또 하나의 문제는'모델과 밀접한 관련이 있는 클래스(예를 들어 Policy나 Observer)'와의 관계를 어떻게 처리하는가이다
끝내다
저는 개인적으로 모드2처럼 모든 것을 앱/MDels 아래에 놓는 형식을 추천하고 싶지만 모드3처럼 종류별로 목록을 자르는 형식은 지금도 그렇게 큰 불만이 없습니다.
상기 이외의 장점과 단점을 느끼는 사람, 또는 상기를 제외하고 우리 집은 이렇게 구성되어 있습니다. 장점과 단점을 함께 알려주시면 큰 도움이 됩니다
Reference
이 문제에 관하여(Laravel 모델 클래스를 어디에 배치할지 고민), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/nunulk/items/e39f25785ad015c8181c텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
