MVC에서 거대한 컨트롤러 또는 많은 컨트롤러를 갖는 것이 더 낫습니까?

MVC에서 거대한 컨트롤러 또는 많은 컨트롤러를 갖는 것이 더 낫습니까?

---

우리는 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 개의 컨트롤러가있을 것입니다.

---

내 겸손한 의견으로는 컨트롤러의 코드를 유지하는 경우 실제로 중요하지 않습니다.

대부분의 코드는 어딘가의 비즈니스 계층에서 발생합니까? 이 경우 컨트롤러에서 실제로 수행하는 작업은 데이터를 뷰로 반환하는 것입니다. 그래야합니다.

컨트롤러를 하위 유형으로 분리하는 팬인지 확실하지 않습니다. 우려의 분리를 유지해야하지만 하위 유형이 너무 멀리 가고 있다고 생각합니다.

이 게시물이 도움이되는지 살펴볼 수 있습니다. 동일한보기 다른 경로

제안한 하위 유형 접근 방식을 사용하는 것보다 더 나은 솔루션 일 수 있습니다.

---

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

EmployeeDeductionController.cs

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

EmployeeBenefitController.cs

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

---

50 개의 컨트롤러를 갖고 싶지 않습니다. 지금은 내 응용 프로그램에 16이 있고 괜찮습니다. 컨트롤러가 50 개있는 경우보기를위한 최상위 폴더도 50 개 있습니다. 작업해야하는 뷰와 컨트롤러를 찾기가 어려울 것입니다. 다른 사람들이 언급했듯이 작업은 일반적으로 짧으며 컨트롤러에 몇 가지 작업이있는 것은 그리 나쁘지 않습니다.

I tried to have 1 controller by system part. I define a system part by taking my database schema and drawing a line around tables that belong together.

---

Why not group them?

Have a structure like,

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

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

Now you can have one payroll controller handling payroll related actions and a general controller which handles regular details of an employee.

---

Another approach we've been using is having a ControllerBase to keep cross-cutting concerns in a common place for CRUD operations. This controller declares the common operations and includes extension points for the specific entity stuff. We had too many code duplication without something like this.

Then, you inherit this controller and create one per entity. And yes, there are many controllers but having so many screens, I don't think it will be the main problem.

Most of the actions accept a complex Model and we play then with the model binders to remove clutter from the controllers. You can see a good post about that here.

Then, using areas like @Odd suggests is a good idea, at least to separate the views because when you have a lot of them is a mess.

Hopefully ASP.NET MVC v2 will bring us areas and encapsulating views in different assemblies (actually that can be done now extending the VirtualPathProvider class).

---

Controllers are meant to be containers for actions under one context. I.E. a customer controller would have actions pertaining to controlling customers. This is particularly suited to CRUD. I would go with fewer larger controllers for this reason. That said, it is really up to you as the application architect to choose the way that best suits your code and just because it is more common to do it one way doesn't mean you have to.

If you have large amounts of code I would suggest you look into ASP.NET MVC areas. You can find excellent posts about it Here in Scott Gu's blog and Here in Steve Sanderson's blog. If you have so many controllers, it might be suitable for you.

Just had a thought after re-reading your post, I suspect your example doesn't come close to the level of complication you have in your code. Perhaps it might help if you posted a situation where you were unsure whether or not it was a good idea to split your controller that is more specific (and less CRUDDY, because CRUD is fairly straight forward).

---

I would organize the controllers roughly around the use cases and their logical grouping. E.g. if you have multiple administrative/HR-type use cases which are likely to be available to a limited group of people, bundle those in one controller. Other controllers could be organized around specific domain model objects - e.g. self-service leave management, salary queries etc. There's no hard and fast rule, you have to create a balance between not putting too much responsibility into a single controller vs. reuse of common internal structures.

Remember also that as much as possible you shouldn't have core business logic in your controllers. They really implement the front-end behavior while the real system rules should be in your domain model and service layer. As long as you keep things roughly within the right layer and reasonably decoupled, you can't go too far wrong with how you place the individual operations within your controllers.

참고URL : https://stackoverflow.com/questions/1197908/better-to-have-huge-controllers-or-many-controllers-in-mvc