Laravel 프로그래밍 아키텍처 설계에서 액션 클래스 사용

이 글은 라라벨 프로그램 아키텍처 디자인 아이디어에서 액션 클래스 활용에 대한 관련 정보를 주로 소개하고 있으며, 샘플 코드를 통해 아주 자세하게 소개되어 있어 공부나 업무에 필요한 모든 분들에게 도움이 될 것입니다. can follow 에디터와 함께 배워볼까요

머리말

어플리케이션의 아키텍처에 관해 이야기할 때 우리는 종종 “이 코드를 어디에 배치해야 할까요?”라는 고전적인 질문을 받습니다. Laravel은 상당히 유연한 프레임워크이기 때문에 이 질문에 대답하기가 쉽지 않습니다. 모델 계층, 컨트롤러 계층 또는 다른 곳에 비즈니스 논리를 작성해야 합니까?

애플리케이션에 액세스 포인트가 하나만 있는 경우 컨트롤러 레이어에 비즈니스 로직을 작성해도 괜찮습니다. 그러나 이제는 동일한 기능 모듈을 호출하는 액세스 포인트가 많은 것이 더 일반적인 상황입니다.

예를 들어, 너무 많은 애플리케이션에는 사용자 등록 기능이 있습니다. 프로세스는 컨트롤러를 호출한 다음 등록 성공 여부를 나타내는 뷰를 반환하는 것입니다. 이 애플리케이션에 모바일 버전도 있는 경우 반환해야 하는 데이터 형식이 JSON이기 때문에 모바일 사용자 등록을 위한 API 세트를 제공할 가능성이 높습니다. 그리고 특히 프로젝트 초기 개발 단계에서 사용자를 생성하기 위해 Laravel의 artisan 명령을 사용하는 것도 매우 일반적입니다.

위 두 코드는 아무런 문제가 없어 보일 수도 있지만, 비즈니스 로직이 증가할수록 코드가 매우 중복되는 것처럼 보일 수 있습니다. 예를 들어 신규 사용자 등록 후 사용자에게 이메일 알림을 보내는 기능을 추가해야 한다면 위의 두 컨트롤러 모두에 이메일을 보내는 코드를 추가해야 합니다. 그러나 코드를 단순하고 우아하게 유지하려면 이러한 비즈니스 논리를 다른 곳에 작성할 수 있습니다.

"비즈니스 로직 코드를 어디에 작성해야 하는지"에 대한 질문에 대해서는 어느 포럼에서나 "서비스 계층을 사용한 다음 컨트롤러 계층에서 이 서비스 클래스를 호출합니다"라는 일반적인 대답을 얻을 수 있습니다. 네, 맞습니다. 문제는 서비스 클래스를 어떻게 디자인해야 하느냐는 것입니다. UserService 클래스를 생성하여 모든 사용자 관련 비즈니스 로직을 구현한 다음 이 클래스를 사용해야 하는 Controller 레이어에 삽입하는 것입니까? 아니면 다른 옵션이 있나요?

신성한 클래스의 함정을 피하세요

먼저, 모든 코드가 포함된 특정 모델에 대한 단일 클래스를 만들어 볼 수 있습니다. 예:

완벽해 보입니다. 모든 컨트롤러에서 생성/삭제 메서드를 선언하거나 사용할 수 있으며 원하는 결과를 얻을 수 있습니다. 하지만 이 구현에 어떤 문제가 있나요? 즉, 문제를 해결하는 과정에서 단일 모델을 거의 사용하지 않습니다.

예를 들어, 사용자를 위한 계정을 생성하는 동시에 해당 사용자를 위한 별도의 블로그도 생성해야 합니다. 이 프로세스를 현재 방식으로 구현하려면 BlogService 클래스를 만든 다음 해당 종속성을 UserService 클래스에 주입해야 합니다.

분명히 애플리케이션 비즈니스가 성장함에 따라 수십에서 수백 개의 서비스 클래스가 있을 것이며, 그 중 일부는 5~6개의 다른 서비스 클래스에 의존해야 하므로 최종 결과는 코드가 중복되고 혼란스러운 상황입니다. 우리는 어떤 대가를 치르더라도 피하고 싶습니다.

싱글 액션 클래스 소개

그래서 하나의 서비스 클래스를 여러 메서드로 사용하는 대신 여러 클래스로 나누기로 했다는 건가요? 다음은 제가 최근의 모든 프로젝트에서 사용한 방법입니다. 결과는 매우 좋으며 모든 사람에게 권장합니다.

먼저, 지나치게 일반적이고 모호한 서비스 용어를 버리고 새로운 액션 클래스를 살펴보고 이것이 무엇인지, 무엇을 할 수 있는지 정의해 보겠습니다.

• 액션 클래스에는 CreateOrder,ConfirmCheckout,DeleteProduct,AddProductToCart 등과 같이 해당 기능을 설명하는 이름이 있어야 합니다.

• API로 공개 메소드가 하나만 있어야 합니다. 이상적으로는 Handle() 또는 Execute() 와 같이 동일한 메서드 이름이어야 합니다. 이는 액션 클래스에 대해 일종의 어댑터 패턴을 구현해야 하는 경우 매우 편리합니다.

• 요청 및 응답에 구애받지 않아야 합니다. 요청을 처리하지 않으며 응답을 보내지도 않습니다. 그러한 책임은 컨트롤러가 져야 합니다.

• 다른 액션 클래스에 따라 달라질 수 있습니다.

• 예상 값의 실행 및/또는 반환을 방해하는 요소가 있는 경우 예외를 발생시켜 관련 비즈니스 로직을 시행해야 하며 호출자(또는 Laravel의 ExceptionHandler)가 렌더링 방법/응답에 대한 책임을 지게 해야 합니다. 예외.

CreateUser 액션 클래스 만들기

이제 이전 예제를 살펴보고 CreateUser라는 이름의 단일 액션 클래스로 리팩토링해 보겠습니다.

이메일 주소가 이미 사용 중인데 왜 이 메서드에서 예외가 발생하는지 궁금할 것입니다. 인증을 요청하면 보장되지 않나요? 확신하는. 하지만 액션 클래스 내부에서 비즈니스 로직을 실행하는 것이 더 좋지 않을까요? 이렇게 하면 논리를 더 쉽게 이해하고 디버그할 수 있습니다.

액션 클래스를 사용한 후 컨트롤러 코드를 살펴보면 다음과 같습니다.

이제 어떤 수정을 하든 사용자 등록 프로세스는 API 및 웹 버전에서 우아하고 깔끔하게 처리됩니다.

액션 클래스 중첩

1000명의 사용자를 애플리케이션으로 가져오기 위해 액션 클래스가 필요하다고 가정해 보겠습니다. 액션 클래스를 작성하고 위에서 CreateUser 클래스를 계속 사용할 수 있습니다.

꽤 깔끔하지 않나요? CreateUser 코드를 Collection::map() 메서드에 삽입하여 재사용할 수 있습니다. 그런 다음 새로 생성된 모든 사용자의 컬렉션을 반환합니다. 이메일이 사용되면 Null 개체를 반환하거나 로그 파일에 기록할 수 있습니다.

액션 클래스 장식

이제 새로 등록된 모든 사용자를 로그에 기록한다고 가정해 보겠습니다. 액션 클래스 내부에 코드를 작성하거나 데코레이터 패턴을 사용할 수 있습니다.

그런 다음 Laravel의 IoC 컨테이너를 사용하여 LogCreateUser 클래스를 CreateUser 클래스에 바인딩할 수 있으므로 후자의 인스턴스가 필요할 때마다 전자가 주입됩니다.

AppServiceProvider.php

이 구성 또는 환경 변수를 사용하여 로깅 기능의 활성화 또는 비활성화를 제어하는 ​​것이 더 편리합니다.

AppServiceProvider.php

Summary

이 방법을 사용하려면 많은 클래스가 필요한 것 같습니다. 물론 사용자 등록은 코드를 짧고 명확하게 유지하도록 설계된 단순한 예일 뿐입니다. 프로젝트의 복잡성이 커지기 시작하면 코드의 위치와 경계를 명확하게 알 수 있기 때문에 액션 클래스의 실제 가치는 점점 더 분명해집니다.

단일 작업 클래스 사용의 이점:

• 작고 단일 논리 도메인은 코드 중복을 방지하고 코드 재사용성을 향상시켜 안정성을 유지할 수 있습니다.

• 다양한 시나리오에 대해 독립적으로 쉽게 테스트할 수 있습니다.

• 대규모 프로젝트에서는 의미 있는 이름을 읽기가 더 쉽습니다.

• 꾸미기가 쉽습니다.

• 전체 프로젝트의 일관성: 코드가 컨트롤러, 모델 등에 분산되는 것을 방지합니다.

물론, 이 방법은 지난 몇 년간 Laravel을 사용한 경험과 일부 프로젝트에서의 실습을 바탕으로 한 것입니다. 이것은 나에게 정말 효과적이었고 이제는 일부 중소 규모 프로젝트에서도 사용합니다.

다른 접근 방식이 있다면 꼭 읽어보고 싶습니다.

위 내용은 이 글의 전체 내용입니다. 모든 분들의 학습에 도움이 되었으면 좋겠습니다. 더 많은 관련 내용은 PHP 중국어 홈페이지를 주목해주세요!

관련 권장 사항:

Laravel 프레임워크는 미들웨어를 사용하여 작업 로깅 기능을 구현합니다.

Laravel 프레임워크는 리스너를 사용하여 SQL 문 기록 기능을 구현합니다.

위 내용은 Laravel 프로그래밍 아키텍처 설계에서 액션 클래스 사용의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!