DDD 및 MVC: '모델'과 '엔티'의 차이

DDD 및 MVC: '모델'과 '엔티'의 차이

저는 MVC의 '모델' 개념에 대해 심각하게 혼란스럽습니다.오늘날 존재하는 대부분의 프레임워크는 모델을 컨트롤러와 데이터베이스 사이에 두고 있으며 모델은 거의 데이터베이스 추상화 계층과 같은 역할을 합니다.컨트롤러가 점점 더 많은 논리를 수행하기 시작하면 'Fat Model Skinny Controller'라는 개념이 사라집니다.

DDD에는 도메인 엔티티(Domain Entity)라는 개념도 있는데, 도메인 엔티티에는 고유한 아이덴티티가 있습니다.제가 알기로는, 사용자는 엔터티(예를 들어 고유한 사용자 ID)의 좋은 예입니다.엔티티는 라이프 사이클을 가지고 있습니다. 즉, 해당 가치는 작업 과정 전반에 걸쳐 변경될 수 있습니다. 그런 다음 저장하거나 폐기됩니다.

위에서 설명한 기업은 MVC에서 모델이 있어야 한다고 생각한 것입니까?제가 얼마나 오프베이스인가요?

더 혼란스럽게 하려면 저장소 패턴과 같은 다른 패턴(서비스를 입력하는 경우도 있음)을 입력해야 합니다.Repository가 엔터티와 어떻게 상호 작용하는지는 매우 분명합니다. 즉, 모델과 어떻게 상호 작용합니까?

컨트롤러에는 여러 개의 모델이 있을 수 있으므로 모델이 고유한 엔티티보다 "데이터베이스 테이블"이 덜한 것처럼 보입니다.

업데이트: 이 게시물에서 모델은 지식이 있는 것으로 설명되며, 단수일 수도 있고 객체의 집합일 수도 있습니다.따라서 기업과 모형은 어느 정도 동일한 것으로 들립니다.모형은 기업이 보다 구체적인 포괄적인 용어입니다.값 개체도 모형이 됩니다.적어도 MVC에 관해서는.아마??

그래서, 아주 대략적으로 말하면, 어떤 것이 더 나을까요?

"모델"은 없어요...

class MyController {
    public function index() {
        $repo = new PostRepository();
        $posts = $repo->findAllByDateRange('within 30 days');
        foreach($posts as $post) {
            echo $post->Author;
        }
    }
}

아니면 이것, DAO로 모델이 있는 것은?

class MyController {
    public function index() {
        $model = new PostModel();
        // maybe this returns a PostRepository?
        $posts = $model->findAllByDateRange('within 30 days');
        while($posts->getNext()) {
            echo $posts->Post->Author;
        }
    }
}

두 예시 모두 위에서 설명한 것을 하지도 않았습니다.분명히 길을 잃었어요.정보는 없습니까?

독립체

Entity비즈니스 로직이 작동하는 단일 항목인 개체를 의미하며, 구체적으로 어떤 종류의 ID를 가진 개체를 의미합니다.
따라서 많은 사람들이 ORM 매핑된 개체를 개체라고 부릅니다.

일부는 인스턴스가 데이터베이스에서 단일 행을 나타내는 클래스를 "entity"라고 부릅니다.

일부 다른 사용자는 비즈니스 규칙, 유효성 검사 및 일반적인 동작을 포함하는 이러한 클래스의 개체만 "entity"라고 부르고 다른 개체는 "데이터 전송 개체"라고 부릅니다.

모델

A ModelUI다=)와이 없는 입니다.View 및 ) (Controller응용프로그램의 데이터 액세스 방식과 응용프로그램의 주요 데이터 추상화 방식에 관한 것입니다.

기본적으로 어떤 것이든 위에 맞는 모델이 될 수 있습니다.

MVC

MVC에서 개체를 모델로 사용할 수 있습니다.그것들은 다른 두 가지를 의미하지만, 같은 클래스는 둘 다라고 부를 수 있습니다.

예

• A Customer클래스는 (일반적으로) 매우 많은 엔티티이며, 앱에서 데이터 액세스의 일부로 사용하기도 합니다.이 경우에는 기업이면서 모형입니다.
• A Repository클래스는 모델의 일부일 수 있지만, 분명히 엔티티가 아닙니다.
• 비즈니스 논리 계층의 중간에 사용하지만 나머지 애플리케이션에는 노출되지 않는 클래스가 있다면, 해당 클래스는 엔티티일 수 있지만 MVC 앱의 관점에서는 모델이 아님이 분명합니다.

너의 예

당신의 코드 예시에 관해서는 첫번째 것을 선호합니다.
모델은 응용프로그램의 데이터 기권의 수단으로 사용되는 클래스이며, 이름에 "모델"이 붙는 클래스가 아닙니다.많은 사람들이 후자의 팽만감을 생각합니다.

Repository 클래스의 이름에 "모델"이 붙지 않더라도 모델의 일부로 간주할 수 있습니다.

첫 번째 코드를 사용하는 것이 더 쉽고 나중에 코드를 이해해야 하는 다른 사람들에게는 더 쉽게 이해할 수 있다는 사실을 덧붙이고 싶습니다.

모든 대답은 서로 다른 것들을 무겁게 매쉬업하는 것이고, 단순히 틀린 것일 뿐입니다.

DDD의 모델은 실제 세계의 모델과 매우 유사합니다. 즉, 무언가를 단순화하고 추상화하는 것입니다.그 이상도 이하도 아닙니다.데이터나 객체, 그 밖의 어떤 것과도 관계가 없습니다.단순히 도메인 부분의 개념입니다.또한 모든 복잡한 영역에는 Trading, Invoice, Logistics와 같은 여러 모델이 항상 존재합니다.

개체는 "정체성을 가진 모델"이 아니라 단순히 정체성을 가진 개체입니다.

저장소는 1단계 캐시일 뿐만 아니라 도메인의 일부이기도 합니다.인메모리 객체에 대한 착각을 불러일으키며 개체가 아닌 Aggregate를 어디서나 가져와 저장합니다. 즉, 객체의 수명 주기를 유지합니다.

응용프로그램의 "모델"은 데이터를 보유하는 비트입니다.도메인 중심 설계의 "엔티"는 제가 정확히 기억한다면 아이덴티티를 가진 모델입니다.즉, 엔티티는 데이터베이스 또는 파일의 "물리적" 요소에 직접적으로 대응하는 모델입니다.DDD는 두 가지 유형의 모델을 정의한다고 생각합니다. 하나는 개체이고, 다른 하나는 가치이며, 이는 단지 정체성이 없는 모델일 뿐입니다.

Repository 패턴은 색인화된 모델/엔트리 모음의 한 유형일 뿐입니다.예를 들어 코드가 주문 #13을 원할 경우 먼저 저장소에 요청하고, 거기서 가져올 수 없다면 어디서든 가서 가져올 수 있습니다.원하신다면 기본적으로 레벨 1 캐시입니다.모델에서 작동하는 방식과 엔티티에서 작동하는 방식에는 차이가 없지만, 저장소의 개념은 ID를 사용하여 모델을 가져올 수 있기 때문에 DDD 측면에서는 엔티티만 저장소로 들어갈 수 있습니다.

서비스 및 수집을 이용한 간단한 솔루션:

<?php
class MyController {
    public function index() {
        $postService = ServiceContainer::get('Post');
        $postCollection = $postService->findAllByDateRange('within 30 days');
        while($postCollection->getNext()) {
            echo $postCollection->current()->getAuthor();
        }
    }
}

EDIT: 모델(클래스)은 엔티티 스킴을 단순하게 표현한 것입니다.모델(객체)은 단일 개체입니다.이 서비스는 모델을 기반으로 운영되며 컨트롤러에 구체적인 데이터를 제공합니다.어떤 컨트롤러에도 모델이 없습니다.그 모델들은 단독으로 서 있습니다.
다른 "측면"에서는 맵퍼가 모델을 저항 계층(예: 데이터베이스, 타사 백엔드 등)으로 매핑합니다.

이것은 특별히 Ruby on Rails에 관한 것이지만, MVC와 DDD에 관한 논의이기 때문에 동일한 원칙과 정보가 여전히 적용됩니다.

http://blog.scottbellware.com/2010/06/no-domain-driven-design-in-rails.html

언급URL : https://stackoverflow.com/questions/3029952/ddd-and-mvc-difference-between-model-and-entity