마 젠토 2 : 모델과 데이터 모델의 차이점


13

Magento 2가 서비스 계약 아키텍처의 일부로 데이터 모델을 도입했음을 알고 있습니다. 데이터 모델은 일반적으로 모듈의 Api / Data /에 정의 된 인터페이스를 구현합니다.

그러나 마 젠토는 기존 모델도 그대로 유지 한 것으로 보입니다.

모듈 고객에게 예를 들어 봅시다.

  • Api / Data / CustomerInterface.php에 정의 된 데이터 모델 인터페이스
  • 위의 인터페이스는 Model / Data / Customer.php에서 구현됩니다.
  • 데이터 모델에는 고객 변수에 대한 모든 getter 및 setter 함수가 있습니다.
  • 위의 것 외에도 Model / Customer.php도 있습니다. 이것도 게터와 세터 기능이 있습니다. 이것은 ResourceModel (Model / ResourceModel / Customer.php)에 연결되는 Magento 1 모델과 비슷합니다.
  • Model / ResourceModel / CustomerRepository.php에서 다양한 함수는 Magnento 1 모델에서 데이터를 수집하여 데이터 모델로 전송 한 다음 데이터 모델을 반환합니다.

왜 오래된 모델이 필요한가요? 데이터 모델이 ResourceModel과 직접 연결할 수없는 이유는 무엇입니까?

답변:


7

내 설명 :

모델과 데이터 모델의 차이점을 이해하는 것은 매우 어렵습니다. 몇 마디로 말하면 모델이 엔진을 나타내고 데이터 모델이 정보를 나타낸다고 말할 수 있습니다 .

예를 들어, 고객 엔티티를 사용하면 메소드 authenticate또는 엔진validatePassword엔진의 일부이고 정보를 직접 처리하지 않기 때문에 고객 모델에 유지 되는 방법을 확인할 수 있습니다 . 반면 getExtensionAttributes에 정보 조각을 처리하는 것이 데이터 모델에 유지되므로 , 같은 방법 이 사용됩니다.

모델과 리소스 모델을 나누는 것처럼 프로젝트 처리가 더 나은 것이라고 생각합니다. 왜 필요한지 물어볼 수도 있습니다.

왜 필요한가 :

API를 사용하여 고객 정보를 노출하려면 (예 :) 엔티티의 모든 속성을 정의하는 게터 가있는 인터페이스 ( \Magento\Customer\Api\Data\CustomerInterface) 가 필요하며 노출하려는 정보를 나타내지 않는 다른 getter 메소드 가있는 경우 (예 : ), 당신은 문제가있다!getRandomConfirmationKey

내 예에서 Thi는 getRandomConfirmationKey모델 ( \Magento\Customer\Model\Customer)의 getFirstname일부이고 데이터 모델의 일부인 이유 입니다.

빠른 규칙은 다음과 같습니다.

  • 메소드가 테이블 열, 속성 또는 모든 유형의 엔티티 정보를 나타내는 경우 data model 로 이동해야합니다 .
  • 메소드가 정보에 대한 "조치"인 경우 정보를 처리하거나 webapi.xml에 선언 하면 모델 메소드 여야합니다 .

우편:

한 마디로 : 데이터 모델을 거의 DTO로 생각하십시오.


\Magento\Customer\Api\Data\CustomerInterfaceREST / SOAP API에 대해 모든 메소드 가 노출됩니다 (활성화 된 경우). 그러나 인터페이스를 '실제'모델에 대신 연결할 수 있으므로 노출 된 메소드를 선택하기 위해 데이터 모델이 필요하지 않습니다. 즉, 함께 이루어집니다 방법입니다 \Magento\Catalog\Model\Product\Magento\Catalog\Api\Data\ProductInterface
밀라노 Simek

2

@ Phoenix128_RiccardoT 답변에 추가하면, 리포지토리 (예 : MagentoCms\Api\BlockRepository또는 Magento\Customer\Api\CustomerRepositoryInterface)는 데이터 모델을 제공하지만 정규 모델이 아닌 데이터 모델을 제공 할 것으로 예상합니다. 데이터 모델은 엔터티가 제공 한 데이터 만 노출하는 표준 모델에 대한 추상화 계층입니다. 이 데이터에 대한 모든 "조치"가 다른 곳으로 이동합니다.

엔티티에 데이터 만 포함되고 엔티티 조작에서 데이터 조작이 수행되는 Symfony2 및 Symfony3의 엔티티 아이디어와 약간 비슷합니다. Magento2 에서이 역할은 리포지토리에 부여되었다고 생각합니다.

이전 모델은 magento2가 개발 된 방식으로 여전히 우리와 함께 있습니다. 그들은 분명히 빈 index.php에서 시작하지 않았지만 M1의 일부 코드를 재사용했습니다. 당신은 표준 모델 방법을 살펴 때 ( load(), save(), 및 delete()) 모두로 표시됩니다 deprecated. 그 작업이 저장소로 이동 되었기 때문입니다 (일부 경우 모든 저장소 가이 일반 모델 save()메소드를 호출 하지만 도로가 나에게 분명해 보입니다).


1
제품 데이터 모델은 어떻습니까? 제품 데이터 모델이 없습니다
sivakumar

2

모델은 스토리지 독립적 인 비즈니스 로직을 캡슐화하고 데이터베이스 엔진 또는 인스턴스에 대해 알지 못합니다. Magento 2에서 데이터 모델은 DTO (데이터 전송 객체 ), Magento CRUD 모델 (모델)에 대한 DTO (데이터 모델) 특정 인터페이스의 구현입니다. )는 Magento WebAPI를 통해 사용 가능한 클래스 메소드를 결정합니다.

Model/Data/Customer.phpAPI에 사용할 수있는 메소드를 결정하지만 Model/Customer.phpAPI 이외의 조작에 사용 가능한 사용자 정의 게터 및 세터의 레거시 Magento 1 유형 구현이 있습니다.

Model/ResourceModel/CustomerRepository.php Magento 2-서비스 계약에 도입 된 새로운 기능의 일부이며 DTO (데이터 모델)의 조합과 함께 작동합니다.

Magento ORM이 모델, 리소스 모델 및 컬렉션으로 구성되고 데이터베이스에 의존한다는 것을 알고 있으므로 서비스 계약의 목적은 저장소 논리를 숨겨서 저장소 (서비스 계약)에 연결된 클라이언트가 대상 스토리지를 신경 쓰지 않도록하는 것입니다. 엔진.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.