MVC - 3 계층 모델입니까?

Question

그냥 mvc를 연구하기 시작했고 아직 이해하지 못했습니다. 내가 수집 한 것으로부터 3 단계 솔루션 즉, 모델은 DAL, 비즈니스 로직 계층의 컨트롤러, 프레젠테이션보기 레이어에 해당합니다.

여기에 기지가 있습니까?

Answer 1

모델을 단순히 데이터 액세스 레이어로 취급하는 것에주의해야합니다. 이는 지나치게 단순화되어 컨트롤러 레이어에 코드를 너무 많이 넣게됩니다. 모델에 더 많은 코드를 넣고 데이터베이스 내구성을 모델의 내부 코드의 일부로 만 만들면 더 좋습니다. 나는이 같은 MVC의 생각하고 싶다 :

• 컨트롤러 : 입력을 처리하는 모델을 결정하고보기
• 보기를 인스턴스화하는 : 응용 프로그램 데이터의 표현
• 모델 : 응용 프로그램에 대한 다른 모든 로직을 포함 DAL

이것은 기본적으로 Page Controller 패턴입니다.

또 다른 방법은 생각해 보겠습니다. 웹 응용 프로그램을 명령 행 응용 프로그램이나 데스크탑 GUI 응용 프로그램과 같은 다른 플랫폼으로 이식해야한다고 가정 해보십시오. 애플리케이션 로직의 어떤 부분을 재사용해야합니까? 입력과 출력의 구현이 변경되어야하기 때문에 컨트롤러와 뷰는 앱을 다른 플랫폼으로 이식 할 때 변경됩니다. 변경하지 않아도되는 코드는 모델에 구현되어야합니다.

문제를 올바르게 구분했다면 모델, 뷰 및 컨트롤러가 최소한으로 결합되어 다른 것에 너무 많은 영향을 미치지 않고 구현을 변경할 수 있습니다. 모델을 변경하고 컨트롤러 또는보기에서 많은 코드를 다시 작성하면이 계층을 적절히 분리하지 않은 것일 수 있습니다. 그 반대.

다른 관점을 얻으려면 Martin Fowler의 Anemic Domain Model 반 패턴 또는 Domain Driven Design Quickly에 대해 읽어보십시오.

내 blog from 2008 또한 Active Record 패턴을 비판하는 사람들에 대한 응답으로 작성했습니다. 좋은 설명과 토론이있었습니다.

Answer 2

일종의. 그것은 다음과 같습니다 : 가장 일반적으로 오늘날 사용

패턴은 다음과 같습니다 당신은 항상하지

DAL == Data Access Layer (aka ORM, Object-Relational mapper) 
BLL == Business Logic Layer 

참고 모든 레이어를 필요로

Database -> DAL -> BLL -> Controller -> View Model -> UI 

. 예를 들어, BLL 및 View Model은 앱이 충분히 작 으면 선택 사항 일 수 있습니다.

NerdDinner tutorial. 체크 아웃해야합니다.이 모든 개념을 단일 참조로 설명합니다. 당신이 MVC를 처음 사용하는 경우 다음과 같이

Answer 3

훌륭한 설명 :

Does anyone beside me just NOT get ASP.NET MVC?

Answer 4

짧은 노트, 당신은 컨트롤러가 비즈니스 계층 일 (하지 않음) 할 수 말할 때 당신이 올바른지, 보기는 표현 계층입니다.

그러나 모델은 데이터가 포함 된 개체 (구현에 따라 다름) 인 반면 데이터 레이어는 데이터를 검색/조작하는 개체입니다.