DataMapper 패턴이 MVC를 중단합니까?

StackOverflow https://stackoverflow.com/questions/1016966

문제

저는 여러 PHP 프레임워크, 특히 Zend Framework에 대해 읽어왔지만 앞으로 나아갈 올바른 방법에 대해 혼란스러워지고 있습니다.

Zend Framework는 ActiveRecords를 사용하지 않고 대신 테이블 데이터 게이트웨이 및 행 데이터 게이트웨이 패턴을 사용하고 DataMapper를 사용하여 행 데이터 게이트웨이의 내용을 모델에 매핑합니다. 모델에 1이 없으면 ActiveRecord가 분해되기 때문입니다. 데이터베이스 테이블에 대한 1개의 매핑입니다.이 있습니다 이것의 예 Zend 빠른 시작 가이드에서.

나에게 있어서 그들의 예는 수많은 getter와 setter로 인해 매우 부풀어 오른 것처럼 보입니다.너무 많은 getter 및 setter를 사용하는 것은 모든 내부 모델 데이터를 외부에 노출하므로 공용 속성에 비해 이점이 없기 때문에 나쁜 습관이라고 주장하는 도메인 중심 설계에 대한 다양한 블로그 게시물을 접했습니다. 여기에 한 가지 예가 있습니다..

내 질문:해당 getter 및 setter를 제거하면 뷰를 어떻게 렌더링합니까?어떤 시점에서는 사용자에게 실제로 무언가를 보여줄 수 있도록 데이터가 뷰에 표시되어야 합니다.DDD 조언을 따르면 MVC에서 M과 V 사이의 분리가 깨지는 것 같습니다.MVC 및 Zend 예제를 따르면 DDD가 손상되고 모든 모델에 대해 수많은 getter, setter 및 DataMappers를 입력하게 됩니다.작업량이 많다는 것 외에도 DRY를 위반하는 것 같습니다.

좋은 예나 모든 것이 어떻게 조화를 이루는 지에 대한 추가 정보(링크)를 제공해 주시면 정말 감사하겠습니다.저는 여기서 건축과 디자인 기술을 향상시키려고 노력하고 있습니다.

도움이 되었습니까?

해결책

값 객체를 사용하면 해당 공개 세터 방법 중 일부를 제거 할 수 있습니다. 다음은 설명입니다 엔티티와 가치 객체의 차이. 가치 객체는 불변이며 종종 엔티티에 묶여 있습니다. 생성자와 함께 모든 값을 전달하는 경우 이러한 속성을 외부 코드에서 설정할 필요가 없습니다.

답과 직접 관련이 없지만 DDD에 더 중점을 둔 추가 사항 :

(면책 조항 : Zend 프레임 워크에 대해 내가 아는 유일한 것은 링크 된 기사에서 읽은 것입니다.) Zend 프레임 워크는 리포지토리 대신 Datamappers를 사용하는 것입니다. 이것이 정말로 DDD-ish입니까? 잘, Fowler의 저장소 해석 거절 할 수도 있습니다. 그러나 Eric Evans는 DDD 저장소가 매우 간단 할 수 있다고 말합니다. 가장 단순하고 저장소 ~이다 Datamapper (DDD 책 참조). 더 복잡하고 여전히 DDD에 대해서는 Fowler 기사를 참조하십시오. DDD에는 패턴 정의와 다른 개념 저장소가 있습니다.

도메인 중심 디자인에 대해 계속 읽어 보시기 바랍니다. 나는 게터와 세터가 DDD를 위반한다는 가정에 결함이 있다고 생각합니다. DDD는 도메인 모델과이를 달성하기위한 모범 사례에 중점을 둡니다. 액세서는 사소한 세부 사항 일뿐입니다.

다른 팁

모든 getters/setter를 구현할 필요는 없으며 __get () 및 __set ()를 사용할 수 있습니다. 그렇다면 문제는 무엇입니까?

게시물을 읽어보니 질문은 실용적이기보다는 철학적인 것 같습니다.

깊이 있게 글을 쓸 시간은 없지만 여기에 2센트가 있습니다.클래스가 내부를 숨겨야 하기 때문에 get 및 set 요청 수를 제한하고 싶다는 데 동의하지만 Java와 PHP는 서로 다른 도구이고 서로 다른 목적을 가지고 있다는 점도 고려해야 합니다.웹 환경에서는 요청이 있을 때마다 클래스가 구축되고 삭제되므로 작성하는 코드가 거대한 클래스에 의존해서는 안 됩니다.당신이 지적한 기사에서 저자는 클래스에 뷰 로직을 배치할 것을 제안했습니다.뷰를 여러 형식(rss, html 등...)으로 표시하려고 하기 때문에 이는 아마도 웹에서는 의미가 없을 것입니다.따라서 접근자 메서드(get & set)를 사용하는 것은 필요악입니다.당신은 여전히 ​​​​발에 총을 쏘지 않도록 신중하게 사용하고 싶습니다.핵심은 수업이 외부에서 작업을 하도록 강요하는 대신 수업이 대신 작업을 수행하도록 하는 것입니다.직접적으로 대신 메소드를 사용하여 속성에 액세스하면 원하는 내부 기능을 숨길 수 있습니다.

다시 한번 말씀드리지만, 이 게시물에서는 몇 가지 예를 사용할 수 있지만 지금은 시간이 없습니다.

왜 접근자 메서드가 나쁘지 않은지에 대한 몇 가지 예를 다른 사람이 제공할 수 있습니까?

여기에는 두 가지 접근 방식이 있습니다. "Tell the Do n't Ask Approach"라고 부르는 것은 ViewModel/DTO 접근 방식입니다. 본질적으로 질문은 당신의 견해에서 "모델"이 무엇인지에 관한 것입니다. 말하지 말아야 할 것은 물체가 외부화 될 수있는 유일한 방법은 물체 자체에서 나온 것입니다. 다시 말해, 렌더링을 위해 렌더링 메소드가 있지만 렌더 메소드는 인터페이스와 대화해야합니다. 이 같은:

class DomainObject {
   ....
   public function render(DomainObjectRenderer $renderer) {
        return $renderer->renderDomainObject(array $thegorydetails);
   }
}

Zend 프레임 워크와 관련하여 Zend_view 서브 클래스를 클래스하고 서브 클래스 가이 인터페이스를 구현할 수 있습니다.

나는 전에 이것을 해냈지만 약간 다루기가 어렵다.

두 번째 옵션은 도메인 모델을 ViewModel 객체로 변환하는 것입니다.이 개체는 단순화되고 평평한 "문자열", 데이터의 뷰, 각 특정 뷰에 대해 사용자 정의 (뷰 당 하나의 뷰 모델 포함) 및 뒤로 돌아가는 길에 변환하는 것입니다. , 게시물 데이터를 EditModel로 변환하십시오.

이것은 ASP.NET MVC 세계에서 매우 인기있는 패턴이지만 응용 프로그램에서 "레이어"사이에 데이터를 전송하는 데 사용되는 클래스 "DTO"패턴과 유사합니다. 더러운 작업을 수행하려면 매퍼를 만들어야합니다 (실제로 데이터 퍼스와 달리). PHP 5.3에서는 반사를 사용하여 개인 속성을 변경할 수 있으므로 DomainObject도 스스로 노출 할 필요조차 없습니다!

Getters and Setters 구현에는 두 가지 장점이 있습니다.

  1. 공개 할 속성을 선택할 수 있으므로 모든 모델의 내부를 노출 할 필요는 없습니다.
  2. AutoComplete와 함께 IDE를 사용하는 경우 "Get"또는 "Set"을 입력하기 시작할 때 사용 가능한 모든 속성이 탭으로 떨어집니다.
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top