该应用程序具有仪表板要求……单个页面可以显示应用程序的许多部分.不同的用户类型获得不同的仪表板.我们已经有了传统的后端,因此第一项任务是构建仪表板,以显示其新的RESTful服务层中的许多位.
我想知道我应该如何从概念上考虑支持这种控制器所需的控制器？
第一个问题是……它们应该是以模型为中心还是以视图为中心？换句话说,它们应该是“以视图为中心”的控制器,其中包含“仪表板”一词吗？或者他们应该更专注于他们所代表的模型元素,例如“任务”,“联系人”,“通知”.或者仪表板控制器应该与模型中心控制器一起使用？
接下来的问题是……控制器应该代表什么级别的粒度？如果以视图为中心的“仪表板”控制器,它们应该是“ManagerDashboardController”和“WorkerDashboardController”吗？如果以模型为中心的控制器,应该有控制器,如“LateTasks”和& “OnTiMetasks”,因为我需要在仪表板的不同部分显示它们,数据略有不同？
我正在寻找基于实际经验和/或对我尚未找到的优秀链接的参考的切实建议.
@H_403_11@控制器应该以模型为中心还是以视图为中心？
这取决于(一如既往),我总是尝试为页面的不同部分设置小型控制器.
页面的某些部分非常以视图为中心(通常是在不同视图之间共享的部分).我通常有一个menuCtrl,一个headerCtrl和footerCtrl.这个ctrls非常适合页面的那些部分,因此使它们以视图为中心.
视图的其他部分,与业务相关的部分更多地耦合到业务规则和模型的扩展,因此我将这些ctrls以模型为中心.在帐户的商业应用程序上,我可能会有一个accountCtrl,一个ownerCtrl,依此类推.通过这样做,如果需要,我可以在不同的视图上重用它们(并且更容易测试)
控制器应该代表什么级别的粒度？
尽可能小.尝试使用小型控制器为页面的不同部分准备模型.如果你有一个大的控制器,将很难测试,维护,你可能会被迫在应用程序的不同部分重复代码.
控制器的建议和重新设计
保持小.
避免在其中使用DOM操作(改为使用指令).
使用控制器只是为了准备模型.尽可能将应用程序的所有逻辑委托给服务.如果你这样做,如果你的控制器是以视图为中心或以模型为中心的话,那真的不重要.
正如我之前所说,这是一个非常主观的问题,我相信很多人会不同意我的看法.
我希望这可以帮到你.
@H_403_11@