在MVC中最好拥有巨大的控制器或许多控制器?
我们正在ASP.NET MVC中构建一个相当大的HR应用程序,到目前为止,我们的控制器变得相当大。 例如,我们有一个员工控制器,并且包含所有员工的意见(个人信息,员工扣除,家属等)。 这些视图中的每一个都可能有多个操作或子视图(例如CRUD)。 每个动作都比较小,但控制器可能有几十个功能。
有没有分裂控制器的最佳做法? 与其拥有几十个视图的Employee控制器,对于每个子类型(比如EmployeePersonalInfoController,EmployeeDeductionController,EmployeeDependentController),是否还会有更好的控制器?
最后,它甚至重要吗?
更新说明
我最初关心的是增删改查措施。 例如,让我们考虑创建和删除...
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个顶层文件夹供查看。 很难找到您需要处理的视图和控制器。 正如其他人提到的那样,动作通常很短,在你的控制器中有几个动作并不坏。
我试图通过系统部分拥有1个控制器。 我通过获取数据库模式并围绕属于一个表的表格绘制一行来定义系统部分。
链接地址: http://www.djcxy.com/p/30177.html上一篇: Better to have huge Controllers, or many controllers, in MVC?