Javascript Angular的新功能：这应该在服务中使用，还是可以保留在控制器中？

我正在处理指令内部正在处理的一小段代码。该指令被传递给一个大的数据对象，该对象分为类型和子类型。使用下拉列表，用户可以选择他们希望在显示中看到的数据的哪一部分，并且应该是动态的，这意味着当他们更改选择时，数据将立即更新。我的第一次尝试是将代码放入附加到指令的控制器中

使用附加到指令的控制器

看法

这种方法工作得很好，但有人向我建议，这不是正确的“角度”方式，所有这些都应该推迟到服务。在这种情况下，不仅需要将数据传递给我的指令，还需要将所有服务方法传递给我的指令。在select下拉列表中，我们需要发出ng change调用，让服务知道值已更改，需要更新

ng-change="setSelectedType({type:type})"

然后，另一个函数可能需要在“Setter”函数运行之后运行，以便重新计算selectedData的动态值。（相当于运行上面的updateDisplay（）

我的总体问题是，将所有这些逻辑移动到服务是否有意义？除了让服务返回过滤数据之外，我还必须在服务端编写getter和setter，并在每次ng更改时调用它们。相反，如果在控制器中完成，则不需要创建任何“setter/getter”对于变量，因为它们被绑定到范围并自动更新（对我来说，使用像angular这样的框架的全部意义）

---

在不让这个问题过于固执己见的情况下，有经验的人能谈谈这个问题吗？

就我个人而言，我不相信硬性的开发规则，但总的来说，我认为大多数开发人员都会同意：

• 如果有的话，您应该有精简（最小）控制器
• 您的业务逻辑应该在服务中
• 指令应仅用于DOM操作

这样说：如果您决定在不同的页面或不同的控制器上重新使用指令，您将怎么做？现在您必须重新编写第一个控制器中的所有代码

然而，如果您使用了服务，那么您只需将指令和服务注入新控制器（并通过控制器将两者链接起来）——工作完成了

---

最后一件事：您希望将指令和控制器之间的交互限制为定义良好的接口。请使用指令中的“scope”属性来实现这一点。

在您的示例中，我看不到任何逻辑。我同意业务逻辑最好位于服务中，因为它有助于从服务的显示方面隐藏该逻辑应用程序

我认为有棱角的方法是使用观察者

scope.$watch('subType',function(subType) {
   scope.selectedData = data[scope.type || 'defaultKey'][subType || 'defaultKey'];
});

不需要有updateData函数，也不需要在页面加载时调用它，因为观察者在第一个摘要期间将至少执行一次

另一个问题是

scope.data

，如果这确实需要在作用域上。如果模板中没有直接绑定到它的内容，则将其保留在作用域之外。这有助于保持作用域与模板中的内容相关。稍后在浏览器中调试并查看作用域

$（$0.scope（））

您将只看到重要的内容

如果范围中有

数据

。您可以这样做。Angular不会在缺少键时出错。除非选择有效，否则模板不会重复

<div ng-repeat="(key, value) in data[type][subType]">
    {{key}}, {{value}}
</div>

{{key}}，{{value}

由于正确的操作方式似乎对您很重要，我强烈建议您使用

控制器作为

语法，而不是输入

$scope

。是的，很好@LionCI感谢您的回答。您能为您的回答添加一些细节吗？您所说的“业务逻辑”是什么意思？在我的示例中是“updateDisplay（）”被认为是这样的吗？我也不知道如果我想在另一个页面中使用我的指令，为什么我必须重新编写代码。该指令是用templateUrl、该指令唯一的控制器和作用域{}定义的这样就可以将大数据对象传递给它。难道我不能在任何其他页面上再次使用该指令吗？没问题！您在问题中用术语“逻辑”描述了业务逻辑：getter/setter、数据操纵等。如果该代码在控制器中，如果该指令绑定到另一个co，则必须重新编写该代码如果代码在服务中，你不会。

scope.$watch('subType',function(subType) {
   scope.selectedData = data[scope.type || 'defaultKey'][subType || 'defaultKey'];
});

<div ng-repeat="(key, value) in data[type][subType]">
    {{key}}, {{value}}
</div>