MVC- 단지 3 계층 모델입니까?

Question

방금 MVC를 연구하기 시작했고 아직 이해하지 못합니다. 내가 수집 한 바에 따르면 3 계층 솔루션 IE 모델의 구현은 DAL, 컨트롤러에서 비즈니스 로직 계층 및 프레젠테이션 계층으로 보는 것처럼 보입니다.

내가 여기서 기지에서 벗어나?

Answer 1

모델을 단순히 데이터 액세스 계층으로 취급하지 않도록주의합니다. 그것은 지나치게 단순화되며 컨트롤러 계층에 너무 많은 코드를 넣습니다. 해당 코드를 모델에 더 많이 넣고 데이터베이스 지속성을 모델의 내부 코드의 일부만 만들면 더 좋습니다. 나는 다음과 같이 MVC를 생각하고 싶습니다.

• 컨트롤러 : 입력 처리, 인스턴스화 할 모델과 뷰를 결정하십시오.
• 보기 : 응용 프로그램 데이터의 프레젠테이션
• 모델 : DAL을 포함하되 이에 국한되지 않는 응용 프로그램의 다른 모든 논리

이것은 기본적으로입니다 페이지 컨트롤러 무늬.

생각하는 또 다른 방법은 다음과 같습니다. 웹 앱을 명령 줄 앱 또는 데스크탑 GUI 앱과 같은 다른 플랫폼으로 포트해야한다고 가정 해 봅시다. 응용 프로그램 논리의 어떤 부분을 재사용해야합니까? 입력과 출력의 구현이 변경되어야하기 때문에 앱과보기가 다른 플랫폼으로 다른 플랫폼으로 포트 될 때 컨트롤러와 뷰가 변경됩니다. 변경할 필요가없는 코드는 모델에서 구현해야합니다.

우려 사항을 올바르게 분리 한 경우 모델,보기 및 컨트롤러가 최소한으로 결합되며 다른 사람에게 너무 많은 영향을 미치지 않고 하나의 구현을 변경할 수 있습니다. 모델을 변경하고 컨트롤러 나보기에 많은 코드를 다시 작성하는 경우이 레이어를 적절하게 분리하지 않았을 것입니다. 그 반대.

Martin Fowler 's에 대해 읽으십시오 빈혈 영역 모델 반포 란 또는 도메인 구동 디자인을 빠르게 구동합니다 다른 관점을 얻기 위해.

또한 내 2008 년 블로그 나는 활성 기록 패턴을 결정하는 사람들에 대한 응답으로 썼다. 좋은 의견과 토론을 받았습니다.

Answer 2

일종의. 다음과 같이 보입니다.

오늘날 가장 일반적으로 사용되는 패턴은 다음과 같습니다.

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

어디에

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

항상 모든 레이어가 필요하지는 않습니다. 예를 들어, 앱이 충분히 작 으면 BLL 및보기 모델이 선택 사항이 될 수 있습니다.

당신은 확인해야합니다 Nerddinner 튜토리얼. 이 모든 개념을 단일 참조로 설명합니다.

Answer 3

MVC를 처음 접한다면 여기에 몇 가지 훌륭한 설명이 있습니다.

내 옆에있는 사람이 Asp.net MVC를 얻지 못합니까?

Answer 4

짧은 참고 사항은 컨트롤러가 비즈니스 계층이 될 수 있다고 말할 때 정확하며,보기는 프레젠테이션 계층입니다.

그러나 모델은 데이터를 포함하는 객체 (구현에 따라 다름)이며 데이터 계층은 데이터를 검색/조작하는 계층입니다.