MVC의 M은 어디에 있습니까?

내 응용 프로그램을 MVC로 리팩토링하려고하지만 M 부분에 붙어 있습니다.

데이터베이스 기반 앱에서 모델은 앱 코드로 구현됩니다.

그러나 데이터베이스에 무엇이 있는가? 그것은 모델이 아닌가?

(데이터베이스를 단순한 객체 저장소로 사용하지 않습니다. DB의 데이터는 엔터프라이즈 자산입니다).

그러나 코드와 데이터베이스의 모델은 모두 "모델"입니다.

모델은 응용 프로그램 "IS"와 관련이 있으며 컨트롤러는 "실행"입니다. 데이터베이스에 대한 직접적인 지속성을 다루는 모든 코드는 모델로 간주됩니다.

참고 : MVC는 패턴 이므로 과도하게 생각하지 마십시오. MVC를 올바른 방식으로 수행하는 것은 쉬운 일이지만, 결국은 마음가짐 일뿐입니다! 즉, 비즈니스 로직을 데이터베이스와 UI에서 유지해야합니다. MVC 이전에는 사람들이 서버에 있어야 할 때 웹 페이지에 비즈니스 로직을 모두 배치했거나 지속성 코드와 함께 비즈니스 로직을 수행하는 데이터베이스에서 많은 스크립트를 실행했습니다. MVC는 사람들이 코드를 재사용 할 수있는 방식으로 생각을 시작하게 만들었으므로 세부 사항에 너무 신경 쓰지 마십시오.

Trygve Reenskaug는 1978 년에 MVC 패턴을 설명 하는 초기 논문을 썼습니다 . 그의 설명에서 모델은 실제 객체, 현상 및 개념을 나타내는 객체 모델이었습니다. 데이터베이스 기반 응용 프로그램의 시나리오에서 모델은 데이터의 투영입니다. 간단히 말하면 모델은 응용 프로그램과 관련된 클래스와 관계입니다.

실제로 MVC에는 일반적으로 도메인 모델 (데이터베이스에 매핑되는 항목)과 응용 프로그램 모델 (오늘 용어에서 뷰 모델이라고도 함)의 두 가지 모델이 사용됩니다. 응용 프로그램 모델은 뷰를 렌더링하기위한 뷰 특정 데이터도 포함하는 도메인 모델의 투영입니다. 이 접근 방식을 MMVC 라고 합니다 . 컨트롤러는 도메인 모델과 직접 상호 작용하고 애플리케이션 모델을보기에 제공합니다. MVVM 패턴에서 애플리케이션 모델과 컨트롤러가 결합됩니다.

1. MVC에는 데이터베이스가 필요하지 않습니다. 모델이 데이터베이스와 대화하는 경우 좋습니다. 또한 플랫 파일로 유지되거나 전혀 유지되지 않을 수 있습니다.

2. 모델은 데이터가 응용 프로그램의 메모리에 저장되는 위치입니다. 또한 모델을 사용하여 데이터에 대한 계산 및 유효성 검사를 수행하려고합니다. 예를 들어, 금리, 용어 및 원칙과 같은 특성을 가진 FinancePayment 모델이 있습니다. 모델에 getMonthlyPayment () 메소드를 추가하여 월별 지불을 계산할 수 있습니다. 컨트롤러 또는보기에서 그렇게하고 싶지 않습니다.

3. 로직이 전혀 없거나 간단한 데이터 바인딩 만 사용하여 뷰가 합리적으로 어둡습니다 ( Martin Fowler 사이트의 Passive View 및 Supervising Controller 패턴 참조 ). 사용자가 버튼을 클릭하는 등의 작업을 수행하면보기에서 이벤트가 발생합니다.

4. 컨트롤러는 이벤트를 처리하고 (사용자가 저장 버튼을 클릭 할 때 일부 코드를 실행) 모델 속성을 설정하고 모델에로드 및 저장 (지속성을 사용하는 경우)을 지시합니다. 컨트롤러는 모델 데이터를 계산하지 않아야합니다. 그러나 컨트롤러에서보기를 대신하여 "if model.profit () <0 then widget.colour = 'red'"와 같은 일부 계산을 수행 할 수 있습니다.

5. 모델을 변경하지 않고 모델의 기능을 잃지 않고 응용 프로그램의 명령 줄 버전으로 전환 할 수 있어야합니다.

ㅏ. 컨트롤러 또는 모델이 아닌보기 만 전환하여 데스크톱 버전과 달리 모바일 버전의 애플리케이션으로 전환 할 수 있습니다. GUI 테스트 프레임 워크없이 모델 및 컨트롤러를 단위 테스트 할 수 있어야합니다.

모델은 프런트 엔드에서 V 및 C에 연결되고 백엔드에서 영구 저장소 (파일에서 SQL / NoSQL 데이터베이스에 이르기까지)에 연결된 코드입니다. db에서 저장하고 db로 저장하는 코드 일뿐만 아니라 (모델의 오해 중 하나임) 실제로 모든 "도메인"작업을 수행하는 코드입니다. 선택, 필터링, 변경, 계산, 결정 데이터. 응용 프로그램의 비 UI 논리를 모두 포함합니다.

매우 단순하고 이상적인 견해를 취합니다.

모델은 일반적으로 데이터 모델이 아니라 도메인 (대개 비즈니스)의 모델로 표시됩니다. 이것들 은 비슷해 보이지만 서로 완전히 연결되어 있지는 않습니다.

뷰는 응용 프로그램 프런트 엔드의 모델이어야하며 컨트롤러는 한 뷰에서 다른 뷰로의 흐름 모델이어야합니다.

비즈니스 로직은 데이터베이스에 있든 코드에 있든 모델에 완전히 캡슐화되어야합니다. View 또는 Controller에서 일부 비즈니스 로직이 반복 될 수 있지만 여러 가지 이유로 이러한 두 구성 요소를 완전히 제거하고 다른 프런트 엔드를 제자리에 배치하는 것이 가능하고 안전해야합니다.

내가 이해하기에 MVC는 클라이언트 응용 프로그램의 아키텍처 패턴에 대한 설명 일뿐입니다. Wikipedia의 그림은 다음과 같습니다.

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

물론 응용 프로그램의 일부가 "저장 프로 시저"로 구현 된 경우 해당 데이터베이스 코드는 모델의 일부이거나 컨트롤러의 일부일 수도 있습니다 (코드의 기능에 따라 다름). 그러나 그렇지 않다면 데이터베이스는 분명히 "MVC 외부"입니다.

But then, what is in the database -- is that not also the model?

전혀 그렇지 않다. " 모델 은 애플리케이션 도메인의 동작 및 데이터를 관리합니다." 모델이 데이터베이스에 연결되는 경우가 종종 있지만 요구 사항은 아닙니다. 모델은 응용 프로그램과 데이터베이스 사이 의 새로운 계층입니다. 백엔드는 일련의 Mock 객체, XML 또는 데이터 지속성을 지원하는 다른 것일 수 있습니다.

계층을 분리하면 더 나은 단위 테스트 방법을 사용할 수있는 유연성이 훨씬 커지고 코드의 관리 용이성 (EG SQL이 Oracle으로 대체 됨)을 다른 이점과 함께 활용할 수 있습니다.

컨트롤러도 마찬가지입니다. MVC는 컨트롤러를 두 계층 사이의 중개인으로 정의합니다. MVC에는 "비즈니스 계층"이 정의되어 있지 않습니다. 오히려, 당신은 당신 자신을 추가합니다. MVC는 대부분의 응용 프로그램을 구축하는 데 필요한 모든 계층을 캡슐화하지 않습니다. 기본 구조에 대한 일반적인 지침 일뿐입니다.

이러한 분리는 제어 역전 기능을 가능하게하는 핵심 요소입니다.

데이터베이스는 모델의 구현 세부 사항입니다. 모델은 전체 도메인 모델이어야하며 데이터와 프로세스를 결합해야합니다. 분리는 프로세스와 해당 프로세스와 관련된 데이터가 아닌 차이의 우려 사이에 있어야합니다.

참조 : http://martinfowler.com/bliki/AnemicDomainModel.html

실제로 "모델"은 데이터 인터페이스의 추상화를 나타냅니다. 그 이유는 다음과 같습니다.

• 데이터베이스는 Model의 일부로 간주 되지만 모델 자체는 아닙니다.
• 모델의 데이터는 데이터베이스, 파일, 웹 서비스에서 가져 오거나 조롱 할 수 있습니다.
• MVC, HMVC 또는 이와 유사한 프레임 워크의 모델 클래스 는 쿼리를 저장해야합니다 ( "지방 모델, 스키니 컨트롤러" 원칙 [ 1 ] [ 2 ] [ 3 ] 참조)

그리고 만약 내가 맞다면 – 누군가가 MVC 컨텍스트 외부의 모델을 언급 할 때, 누군가 가 데이터 의 구조 (예 : 스키마 )를 언급 할 가능성이 높습니다 .

M에는 논리가 포함되어 있고 데이터를 DB에 저장한다고 생각합니다. 컨트롤러는 실행할 모듈을 호출하고이 모듈은 로직을 실행하고 DB에 데이터를 저장 한 후 (영구 계층이있을 수 있음)이 모듈은 값을 V로 반환합니다.

MVC의 M (odel)은 한 곳에서 비즈니스 / 도메인 의 모델 을 캡처해야합니다 .

도메인의 비즈니스 규칙 과 구조 가 이상적으로 포함되어야합니다 .

C (controller)는 비즈니스 모델의 정보를 프리젠 테이션 (예 : 뷰)에 중재하고 V (iew)에서 사용자 입력을 캡처하여 모델 상태의 변경을 시작하는 것에 이상적입니다.

데이터베이스 계층은 특정 시점에서 모델 상태의 지속성을 처리합니다 (또는 처리해야합니다).

따라서 그것은 무언가가 아니다 속한 하나에 모델 또는 컨트롤러 MVC 패턴의 일부가 아니라, 그것은 외관의 함수로 (투명 모델에 변화를 지속하여 암시 적으로 구현 될 수있는 완전히 별개의 관심사는을 제공한다 컨트롤러와 모델과의 상호 작용) 또는 모델에 대한 변이를 완료 한 후 컨트롤러가 명시 적으로 호출하는 것보다 자주 수행됩니다.

이상적인 세계의 모델에는 비즈니스 로직 만 포함되어야하며 하우스와 같은 실제 객체를 모델링합니다. 그러나 거의 모든 상황에서 모델은 데이터를 일부 스토리지에 유지해야합니다.

모델과 저장된 데이터 간의 상호 작용은 별도의 데이터 계층에서 또는 모델에서 직접 발생할 수 있습니다 (ORM (Object Relational Mapper) 사용시). 다시 말해, 모델은 데이터베이스에 직접 연결되거나 데이터베이스에 연결되는 다른 "데이터 액세스"개체로 데이터를 전달합니다.

ORM (Object Relation Mapper)은 데이터베이스 테이블의 필드를 모델 오브젝트의 속성에 맵핑하여 게터 및 세터를 제공합니다. 이 경우 별도의 데이터 계층이 없으며 모델은 데이터를 직접 유지해야합니다.

다음은 ActiveRecord널리 사용 되는 ORM을 사용하는 Ruby 예제입니다 .

class House < ActiveRecord::Base
end

house = House.new
house.price = 120000
house.save

Pricegetter 및 setter를 오브젝트에 추가하여 houses자동으로 감지되는 테이블 의 필드입니다 ActiveRecord. 때 save호출되는 가격 속성의 값은 데이터베이스에 유지됩니다.

내 관점에서 볼 때 데이터 레이어를 사용하는 전문가는 모델에 도달하기 전에 데이터를 조작 할 수있는 지점을 확보하고 모델에 대한 걱정이 적고 책임이 적다는 점입니다. 예를 들어, 호환되지 않는 여러 데이터 소스의 데이터를 결합해야 할 수도 있습니다. 이는 ORM이 쉽게 처리 할 수없는 것입니다.

주요 단점은 관리해야 할 또 다른 추상화 계층이며, 필요하지 않은 경우 간단하게 유지하십시오. 움직이는 부품이 적고 잘못 될 가능성이 적습니다.

그래 당신 말이 맞아요.

(모델 뷰 컨트롤러)

사용자 인터페이스 (보기) 및 처리 (컨트롤러)와 데이터 (모델) 를 분리하는 응용 프로그램을 구축하기위한 아키텍처입니다 .

실제로 MVC 뷰와 컨트롤러는 밀접하게 관련되어 있기 때문에 종종 단일 객체로 결합됩니다. MSDN 에 따르면

컨트롤러는 사용자의 마우스 및 키보드 입력을 해석하여 모델 및 / 또는 the view to change as appropriate.

이 다이어그램을 확인하십시오.

예를 들어, 컨트롤러 코드는 데이터 요청의 유효성을 검사하고 뷰에서 반환되도록합니다. 뷰 컨트롤러 객체는 하나의 모델에만 연결됩니다. 하나,a model can have many view-controller objects associated with it.