MVC 내의 N 계층

Question

웹 양식에서 MVC로 이동 중이며 약간 손실됩니다. 제 질문은 거의 MVC Vs n-tier architecture에 의해 답변되었지만별로 대답하지 않았습니다.

웹 양식의 경우 일반적으로 내 솔루션 아래에 3 개의 프로젝트로 사이트를 구축합니다. UI, BLL 및 DAL과 아마도 하나의 테스트 (나는 이것이 일반적인 관행이라고 생각합니다).

이제 MVC3을 시작했는데 Visual Studio가 나를 어떻게 배치하는지에 따라 3을 분리 할 필요가없는 것으로 보입니다.

MVC는 여러 프로젝트에서 실행되도록 설계 되었습니까? 아니면 하나의 프로젝트에서만 실행해야합니까? 웹 폼은 N 계층 응용 프로그램에 적합하지만 내 모델 폴더를 삭제하고 DAL로 옮기고 컨트롤러 폴더를 삭제하고 BLL로 이동하여 MVC N 계층을 만들 수는 있지만 MVC가 내가 원하는 것을 싸우는 것 (또는 아마 비주얼 스튜디오가 어떻게 설정하는지)? 또는 모델과 컨트롤러를 그대로 유지하고 Model 폴더에 'viewmodel'을 만들고 컨트롤러가 대부분의 로직에 대해 BLL과 대화를 나눕니 까? 모든 포인터가 좋을 것입니다.

Answer 1

MVC는 프리젠 테이션 패턴 일 뿐이므로 프리젠 테이션 로직을 어떻게 구성해야하는지에 대해서만 설명합니다. 데이터 액세스 패턴이나 비즈니스 도메인 구성 방법에 대해서는 언급하지 않았습니다.

웹 프로젝트 (MVC), 모델 (도메인) 프로젝트, 앱에 따라 데이터 액세스 및/또는 서비스 프로젝트에서 웹 앱을 구조화하는 경향이 있습니다. 나는 웹 프로젝트의 모델 폴더를 항상 삭제하고 싶다. 모든 내 도메인 모델과 뷰 모델은 모델 프로젝트에 있습니다.

컨트롤러에 대해 컨트롤러는 사용자가 수행하고자하는 요청 (요청)에 대해서만 번역자가되어야하므로 모델과 뷰가 그에 따라 응답 할 수 있습니다 (응답). 나는. 컨트롤러는 너무 얇아서 간신히 알아 차려야합니다. 컨트롤러에는 모델을 선택하는 로직과 표시 할 뷰가 있어야합니다. 다른 모든 로직은 모델에 속합니다.

또한보기에는 if 및 foreach와 같은 매우 간단한 표현 논리 만 포함해야하지만 조건은보기 모델에서 준비되어야합니다.

Answer 2

MVC 모델은 UI 전용입니다. 이전과 동일한 우려를 계속할 수 있습니다.

우리 프로젝트에서 우리는 웹 프로젝트의 웹 사이트 레이어와 뷰 모델을 유지합니다. 우리는 WCF 서비스를 데이터 액세스에 사용합니다 (귀하의 DAL에 해당). 격차를 메우는 것은 서비스에 대한 클라이언트 측 액세스와 서비스 결과에서 뷰 모델까지 발생해야하는 모든 번역을 포함하는 논리 프로젝트 (비즈니스 로직에 해당)입니다.

컨트롤러와 뷰 모델 모두 매우 얇습니다. 논리는 논리 계층과 별도로 유지되는 도메인 모델에 있습니다. 일반적으로 서비스 계약 (귀하의 경우 DAL)과보기 모델간에 도메인 모델을 공유하지만보기 모델은 결코 도메인 모델을 직접 노출하지 않습니다.

이 정보가 도움이되기를 바랍니다.