데이터베이스에 정보를 유지하기위한 여러 구성을 보았습니다. 일반적으로 세 가지 유형의 디자인이 세계 곳곳에서 일반적으로 보입니다.
- 컨트롤러는 지속성을 관리합니다
- 지속성을 관리하는 모델
- 타사 라이브러리는 지속성을 관리하며 일반적으로 모델에 대한 일종의 주석이 필요합니다.
개념적으로 MVC 아키텍처와 가장 사용하기 쉽고 호환되는 구성이 궁금합니다.
(제가 목록에없는 것이면 답변의 일부로 빠른 개요 / 개요를 제공하십시오)
답변
두 번째와 세 번째 옵션은 동일합니다. MVC의 M은 데이터 모델이 아니라 도메인 모델입니다. 여기에는 직접 또는 ORM을 통한 지속성도 포함되며 완벽하게 정확합니다.
컨트롤러는 사이트의 흐름을 관리하고 처리 할 도메인 (때로는 서비스 계층을 통해)으로 물건을 전달하여 잘못되었거나 적어도 의미 적으로 불편한 상황이 지속됩니다.
답변
현실적으로 MVC는 대부분 UI 구현 패턴이므로 문제는 다소 무의미합니다. 그러나 실제로 큰 그림 옵션은 두 가지뿐입니다. 컨트롤러는 일반적으로 1) 일종의 서비스 계층 또는 2) 활성 레코드 패턴을 사용하여 모델에서 엔티티를로드하거나 저장하라는 요청을 발송합니다.
서비스 계층은 다양한 형태를 취할 수 있지만 개인적 선호는 집계 루트 엔티티에 대한 저장소 추상화를 사용하는 것이지만 구체적인 구현은 일종의 ORM 또는 경량 DAO 또는 응용 프로그램에 적합한 일부 비 관계형 저장소에 대한 API.
활성 레코드 패턴은 모델이 지속성에 대한 책임이 있음을 의미하지만 일반적으로 일종의 기본 클래스가 상점에 대한 맵핑을 관리하므로 모델이 실제로 직접 관련되지는 않습니다.
기본적으로 컨트롤러는 저장소, UnitOfWork 구현 또는 엔티티의 Save 메소드에 대한 호출 여부에 관계없이 오브젝트를 유지하기위한 요청을 발송합니다. 리포지토리를 사용하는 경우 모델 개체는 지속성을 무시합니다.
답변
MVC (model-view-controller) 시스템에서 모델에는 데이터가 포함됩니다. 따라서 데이터베이스 지속성이 있어야한다고 생각합니다.
답변
내가 본 대부분의 고급 MVC 샘플 infrastructure에는 실제 데이터베이스 구현 코드 (즉, NHibernate, EF 또는 Linq에 대한 특정 호출 또는 데이터 계층이 무엇이든) 가있는 별도의 계층이 있지만 “모델”계층 (종종 “도메인”레이어)에는 데이터 서비스를 정의하는 인터페이스 가 있습니다.
답변
MVC의 표준 관행은 M (odel) 레이어에 데이터 구조와 지속성을 포함시키는 것입니다.
모델 계층에는 응용 프로그램에서 사용할 클래스 (POCO 등) 만 포함되지 않습니다. 여기에는 해당 클래스의 저장소가 포함됩니다.
예를 들어 많은 데이터 클래스 인스턴스가있는 저장소는 다음과 같습니다.
Clients repository
AllClients()
RecentClients()
ClientByID(int id)
모델 도메인을보다 효과적으로 구성 할 수 있으며 여러 가지 방법으로 데이터에 액세스 할 수 있지만 여전히 데이터 / 모델 계층은 작고 강력합니다.