거대한 컨트롤러 또는 많은 컨트롤러를 MVC에 두는 것이 좋습니까?

Question

ASP.NET MVC에서 상당히 큰 HR 응용 프로그램을 구축하고 있으며 지금까지 컨트롤러가 상당히 커졌습니다. 예를 들어 직원 컨트롤러가 있고 모든 직원보기가 포함됩니다 (개인 정보, 직원 공제, 피부양자 등). 각보기에는 여러 작업 또는 하위보기 (예 : CRUD)가있을 수 있습니다. 각 동작은 비교적 작지만 제어기에는 수십 개의 기능이있을 수 있습니다.

컨트롤러를 분할하는 모범 사례가 있습니까? 수십 개의 뷰가있는 Employee 컨트롤러가있는 대신 각 하위 유형 (예 : EmployeePersonalInfoController, EmployeeDeductionController, EmployeeDependentController)에 대해 하나의 컨트롤러가 있어야할까요?

마지막으로 중요합니까?

내 원래 관심 해명 업데이트

은 CRUD 작업과 함께했다. 예를 들어,에는 EmployeeController에 ...의 생성 및 삭제를 고려

현재 작업을하자

CreateEmployee() 
    DeleteEmployee() 
    CreateEmployeeDeduction() 
    DeleteEmployeeDeduction() 
    CreateDependent() 
    DeleteDependent() 
    etc. 

을 컨트롤러가 분리 된 경우 : 첫번째 시나리오에서

EmployeeController 
    Create() 
    Delete() 
    EmployeeDeductionController 
    Create() 
    Delete() 
    EmployeeDependentController 
    Create() 
    Delete() 
    EmployeeBenefitController 
    Create() 
    Delete() 
    etc. 

, 우리 ~ 100 화면은 8-10 개의 대형 컨트롤러로 분할됩니다. 두 번째로, 아마 ~ 50 개의 컨트롤러가있을 것입니다.

Answer 1

나의 겸허 한 의견으로는 컨트롤러에 코드를 보관하는 것이 중요하지 않은 경우입니다.

대부분의 코드는 어딘가에 비즈니스 계층에서 발생합니다. 그렇다면 컨트롤러에서 실제로하는 모든 작업이 데이터를 뷰로 반환하는 것입니다. 그것이 있어야하는 것처럼.

컨트롤러를 하위 유형으로 구분하는 팬인지 확실하지 않습니다. 염려의 분리를 유지해야하는 동안 나는 아형 유형이 너무 멀다고 생각합니다.

이 게시물을 통해 도움이되는지 확인할 수 있습니다. Same View Different Paths

제안한 하위 유형 접근 방식을 사용할 때보 다 더 좋은 해결책 일 수 있습니다.

Answer 2

왜 그룹화하지 않으시겠습니까?

는

employee/payroll/ 
    employee/payroll/giveraise 
    employee/payroll/manage401k 

employee/general/ 
    employee/general/address 
    employee/general/emergencycontact 

는 이제 하나의 급여 급여 관련 작업을 처리하는 컨트롤러와 직원의 정기적 인 세부 사항을 처리하는 일반적인 컨트롤러를 가질 수와 같은 구조를 가지고.

Answer 3

컨트롤러는 하나의 상황에서 작업을 수행하는 데 사용되는 컨테이너입니다. I.E. 고객 제어기는 고객 제어와 관련된 조치를 취합니다. 이것은 특히 CRUD에 적합합니다. 이런 이유로 더 적은 수의 컨트롤러로 갈 것입니다. 즉, 응용 프로그램 설계자는 코드에 가장 잘 맞는 방법을 선택하는 것이 아니라 한 가지 방법으로 수행하는 것이 더 일반적이기 때문에 자신이해야하는 것은 아닙니다.

많은 양의 코드가 있다면 ASP.NET MVC 영역을 살펴 보시기 바랍니다.우수 게시자는 Here in Scott Gu's blog 및 Here in Steve Sanderson's blog입니다. 컨트롤러가 너무 많으면 적합 할 수도 있습니다.

게시물을 다시 읽은 후 생각해봤을 때, 귀하의 예가 귀하의 코드에있는 합병증의 수준에 근접하지 않는다고 생각됩니다. 아마도 좀 더 구체적이고 (CRUDY가 적다는 이유로 CRUD가 상당히 간단하기 때문에) 컨트롤러를 나누는 것이 좋은 아이디어인지 여부를 확신 할 수없는 상황을 게시 한 경우 도움이 될 수 있습니다.

Answer 4

Partial classes을 사용하면 클래스를 여러 파일에 분산시킬 수 있습니다. 이렇게하면 컨트롤러의 관련 영역을 별도의 파일로 그룹화 할 수 있지만 모든 컨트롤러는 여전히 동일한 컨트롤러에 포함됩니다. 예 :

EmployeeDeductionController.cs

public partial class EmployeeController 
{ 
    public ActionResult Deduct() 
    { 
    } 
    // etc 
} 

EmployeeBenefitController.cs

public partial class EmployeeController 
{ 
    public ActionResult GiveBenefit() 
    { 
    } 
    // etc 
} 

Answer 5

나는 50 컨트롤러를 갖고 싶어하지 않을 것이다. 지금 나는 나의 신청에서 16가 있고 저것은 좋다 느낀다. 컨트롤러가 50 개인 경우 뷰의 최상단 폴더가 50 개가됩니다. 당신이 작업 할 필요가있는 뷰와 컨트롤러를 찾는 것은 어려울 것입니다. 다른 사람들이 언급 한 행동이 일반적으로 짧기 때문에 컨트롤러에 몇 가지 조치를 취하는 것이 그리 좋지 않습니다.

시스템 부분별로 1 개의 컨트롤러를 사용하려고했습니다. 필자는 데이터베이스 스키마를 사용하고 함께 속하는 테이블 주위에 선을 그려 시스템 파트를 정의합니다.

Answer 6

컨트롤러를 대략적으로 사용 사례와 논리적 그룹으로 구성 할 것입니다. 예 : 제한된 그룹의 사용자가 사용할 수있는 관리/HR 유형의 여러 사례가있는 경우 하나의 컨트롤러에 해당 사례를 묶습니다. 특정 도메인 모델 객체를 중심으로 다른 컨트롤러를 구성 할 수 있습니다. 셀프 서비스 휴가 관리, 급여 쿼리 등이 있습니다. 어렵고 빠른 규칙은 없으며 단일 컨트롤러에 너무 많은 책임을 부여하지 않고 일반적인 내부 구조를 재사용하는 것 사이에 균형을 유지해야합니다.

가능한 한 컨트롤러에 핵심 비즈니스 로직이 없어야 함을 기억하십시오. 실제 시스템 규칙은 도메인 모델 및 서비스 계층에 있어야하는 반면 실제로 프런트 엔드 동작을 구현합니다. 올바른 레이어 내에 물건을 대략적으로 보관하고 합리적으로 분리하면, 컨트롤러 내에서 개별 작업을 수행하는 방법에 대해 너무 잘못 될 수 없습니다.

Answer 7

우리가 사용 해본 또 다른 접근법은 CRUD 작업을 위해 일반적인 장소에서 교차 절단 문제를 유지하는 ControllerBase를 사용하는 것입니다. 이 컨트롤러는 일반적인 작업을 선언하고 특정 엔터티에 대한 확장 점을 포함합니다. 우리는 이와 같은 코드없이 너무 많은 코드 중복이있었습니다.

그런 다음이 컨트롤러를 상속하고 엔티티 당 하나씩 만듭니다. 그리고 네, 많은 컨트롤러가 있지만 너무 많은 스크린을 가지고 있기 때문에, 그것이 주요 문제가 될 것이라고는 생각하지 않습니다.

대부분의 작업은 복잡한 모델을 허용하며 모델 바인더를 사용하여 컨트롤러에서 불필요한 부분을 제거합니다. 그 글에 대한 좋은 소식을 here에서 볼 수 있습니다.

그런 다음 @Odd와 같은 영역을 사용하는 것이 좋은 생각입니다. 적어도 많은보기가 분리되어있을 때보기가 분리되기 때문에 적어도 엉망입니다.

잘하면 ASP.NET MVC v2를 사용하면 다른 어셈블리에서 영역을 캡슐화하고 뷰를 캡슐화 할 수 있습니다 (실제로 VirtualPathProvider 클래스를 확장하여 수행 할 수 있음).