所以,我正在进行我的第一个 Angular 重大项目。我有一个控制器正在做大量的跑腿工作,它已经达到了数千行 JavaScript 的地步。
我想以某种方式打破这个,但我似乎无法在任何地方找到一个可靠的例子。代码主要由用于对对象进行计算的函数组成,因此指令和模块似乎不是正确的答案,但我可能错了。
你们是如何在大型 Angular 项目中组织代码的?我应该把它吸起来,还是有一种理智的方法可以把它分成易于扫描的文件?
所以,我正在进行我的第一个 Angular 重大项目。我有一个控制器正在做大量的跑腿工作,它已经达到了数千行 JavaScript 的地步。
我想以某种方式打破这个,但我似乎无法在任何地方找到一个可靠的例子。代码主要由用于对对象进行计算的函数组成,因此指令和模块似乎不是正确的答案,但我可能错了。
你们是如何在大型 Angular 项目中组织代码的?我应该把它吸起来,还是有一种理智的方法可以把它分成易于扫描的文件?
我建议至少将其中一些对象及其相关计算放入服务中,然后将服务注入您的控制器中。有关封装某些数据并提供访问/操作该数据的方法的服务示例,请参阅Sticky Notes 第 1 部分博客条目。
看看你是否可以把你的控制器分成多个控制器,每个视图一个。视图可以和页面一样大,或者只是页面上的一些块/块。
引用我最近看到的谷歌小组帖子:“我更喜欢将角度控制器视为我的观点的愚蠢 api/configs,并将所有繁重的工作留给服务。” --参考
当您在控制器中时,您需要问自己一些事情。
您是否在控制器中进行任何 DOM 操作?这是一个明确的 NO。永远不要那样做。它始终属于指令部门。
您是否在控制器中编写任何业务逻辑?这也是一个NO。在大多数情况下,您的业务逻辑应该存在于服务中。那是合适的地方。
现在,看看你的控制器。它是否没有这两件事并且仍然大于 1000 行?这是极不可能的,但即使它以某种方式发生,也要考虑将你的控制器分解成更小的控制器。这种对控制器的破坏必须基于视图来完成。
总而言之,您的控制器只是将业务逻辑和视图粘合到 HTML 中的地方。从技术上讲,它不应该包含这些胶水以外的任何东西。
我通常创建一个 Util 工厂(似乎是现在在 Angular 而不是服务中的方式)并让它返回任何共享逻辑作为一组方法。