如何思考angularjs中的控制器

Question

我正在和Angularjs擦肩而过,并且认为我会在SO的优秀人群中提出一个概念性的问题.这是来自经验丰富的开发人员的新手问题.

该应用程序具有仪表板要求......单个页面可以显示应用程序的许多部分.不同的用户类型获得不同的仪表板.我们已经有了传统的后端,因此首要任务是构建仪表板,以显示其新RESTful服务层中的许多位.

我想知道我应该如何从概念上考虑支持这种控制器所需的控制器？

第一个问题是......它们应该是以模型为中心还是以视图为中心？换句话说,它们应该是"以视图为中心"的控制器,其中包含"仪表板"一词吗？或者他们应该更专注于他们所代表的模型元素,例如"任务","联系人","通知".或者仪表板控制器应该与模型中心控制器一起使用？

接下来的问题是......控制器应该代表什么级别的粒度？如果以视图为中心的"Dashboards"控制器,它们应该是"ManagerDashboardController"还是"WorkerDashboardController"？如果以模型为中心的控制器,应该有控制器,如"LateTasks"和"OnTimeTasks",因为我需要在仪表板的不同部分显示它们,数据略有不同？

我正在寻找基于实际经验和/或对我尚未找到的优秀链接的参考的切实建议.

Answer 1

以下是我过去6个月在Angular开发业务应用程序的观点:

控制器的作用

1. 初始化(加载初始数据,设置选项)
2. 通过$ scope将变量和函数公开给模板
3. 应用程序流程(通过暴露可以改变状态的函数或$watches)

我发现,与传统的MVC框架非常相似,Angular应用程序中的控制器应该非常超薄.控制器中应该存在很少的业务逻辑,而应该将其封装在模型中.在听到MiškoHevery的演讲后,我得出了这个结论:" 范围的目的是参考模型,而不是模型." 这是我从该演示文稿中获得的最有价值和最有启发性的一句话(尽管我建议观看整个视频); 这条线直接导致我减少了近50%-70%的控制器.

例如,我的公司有一个概念Order.我创建了一个模型,它封装了这个业务对象的所有属性,以及它的行为,并将它们注入到控制器中.我们有一个业务规则是能够添加Booking(另一个业务对象)Order.最初在我的控制器中,我有一个$scope.addBooking功能,首先创建一个新的Booking,然后接受订单并做了一个$scope.order.bookings.push(newBooking).相反,我将这个业务逻辑(addBooking函数)直接移动到我的Order模型中,然后在模板中我可以做一些事情,<button ng-click="order.addBooking()">Add Booking</button>而不需要在我的控制器中添加一行代码.

当我第一次开始使用angular时,我在控制器中放了很多代码,我发现它可以被剥离并放在我的模型,指令或服务中(在我的情况下大多是前两个).我控制器中留下的其余代码几乎都属于上面列出的上述3个角色之一.它是初始化代码(例如,触发AJAX请求以获取相关业务对象的数据),对象的范围分配,或处理应用程序流的函数的范围分配(例如,$scope.save或者$scope.cancel可能将您发送回不同的页面).

控制器应该是以模型为中心还是以视图为中心？

这是一个有趣的问题,我以前没有想过.当我听到以视图为中心时,我想到了一个主要处理视图和事物显示方式的控制器.我觉得不应该有任何纯粹以视图为中心的控制器,原因是看起来以视图为中心的控制器可能会被转换为指令.您提到以视图为中心的控制器就像一个Dashboard控制器,听起来像是一个绝对可以制成通用指令的东西.您的指令应该封装大部分视图逻辑,而您的控制器专注于简单地将模型暴露给视图以供消费(回到控制器的角色).这让我觉得控制器应该更多地以模型为中心.

我认为我能得出的唯一结论是,如果控制器开始变得过于以视图为中心(许多变量和函数主要处理视图和UI行为),那么这表明控制器的某些部分可以被拔出进入一个指令,使你的控制器更苗条.

Answer 2

这是非常主观的，但这是我对你的问题的回答

\n\n

控制器应该以模型为中心还是以视图为中心？

\n\n

这取决于（一如既往），我总是尝试为页面的不同部分使用小型控制器。

\n\n

页面的某些部分非常以视图为中心（通常是在不同视图之间共享的部分）。我通常有一个menuCtrl、一个headerCtrl 和footerCtrl。该控件与页面的这些部分非常耦合，因此使它们以视图为中心。

\n\n

视图的其他部分，即与业务相关的部分，与业务规则的耦合程度更高，并扩展到模型，因此我使这些 ctrls 以模型为中心。在 account\xc2\xb4s 业务应用程序上，我可能会有一个 accountCtrl、一个ownerCtrl 等等。通过这样做，如果需要，我可以在不同的视图上重用它们（并且更容易测试）

\n\n

控制器应该代表什么级别的粒度？

\n\n

尽可能最小。尝试使用小型控制器为页面的不同部分准备模型。如果您有一个大控制器，它将很难测试和维护，并且您可能被迫在应用程序的不同部分上重复代码。

\n\n

与控制者的建议和建议

\n\n

保持它们很小。

\n\n

避免在其中进行 DOM 操作（改为使用指令）。

\n\n

使用控制器只是为了准备模型。只要有可能，将应用程序的所有逻辑委托给服务。如果您这样做，那么如果您的控制器是以视图为中心或以模型为中心，那么它就不会那么重要。

\n\n

正如我之前所说，这是一个非常主观的问题，我确信很多人会不同意我的观点。

\n\n

我希望这可以帮助你。

\n