Question

我正在使用Ionic构建我的第一个Angular 2应用程序，并正在构建一些服务。本教程不使用静态方法，但对我来说，似乎在我的用例中，静态方法和属性是可行的方法。不使用静态方法将是这样的：

import {MyService} from "../services/MyService";
@Component({
  templateUrl:"page.html",
  providers: [MyService]
})

export class MyNewClass{
    constructor(private myService: MyService){}

    //to use:
    this.MyService.get()
}

VS

import {MyService} from "../services/MyService";
@Component({
  templateUrl:"page.html"
})

export class MyNewClass{
    constructor(){}

    //to use:
    MyService.get()
}

现在在我的用例中，MyService数据在整个应用中都没有变化。我一次加载数据，需要在整个应用程序中使用它。我想在MyService中有一个静态数组，其中包含所有其他类使用的信息。在我看来，对此的好处是很明显整个应用程序中只有一个实例 - 没有猜测。此外，我不必写providers: [MyService]，也不必将其注入构造函数中，我认为这将是一件非常好的事情，因为我不想要构造函数由于长度而变得不可读的参数。这有什么不对吗？

Answer 1

如果你真的讨厌providers: [MyService]，虽然不是真正的建议练习，你可以引导它：bootstrap(AppComponent, [MyService])。

针对静态方法的一些缺点是：

在服务中不是标准习语/风格：你会让人们问这个案例中有什么特别的东西让你这么写 - 你也可能会有更难的时间试图关注Style Guide。
- 也许您应该考虑实施独立功能并将其导出
```
export function getStuff() { ... }
export function foo() { ... }
```
  然后
```
import { getStuff, foo } from './shared/stuff';
```
一般来说，静态内容在代码中更难（或更不自然），无论是在测试环境中还是仅仅在运行时（想想多态）。

现在，由于这些原因并非真正的技术块（例如，您的服务中需要任何角度注入功能），现在您可以说它沸腾了归结为意见。

因此，如果您的测试（也称为技术）需求得到满足，请与您的团队交谈，并使用每个人认为最好的事情（也就是解决意见重要的旧学校方式）。如果他们对非标准的测试和使用该服务的方式没有问题，那就去吧（只要它有效......）。

有没有理由不在角度2中使用静态类方法？

1 个答案: