订阅角度服务中的可观察对象

时间:2020-09-01 15:06:59

标签: angular architecture flux

我在Angular中从事一个中型项目。我对架构存在一些疑问:

  1. 参加一个项目后,我决定创建一个四层架构。
    • 第一层是数据存储服务层,它们是 数据。他们所有人都可以调用某种API抽象,然后 他们将数据存储在公共观察站中,并通过 私人行为主体。

    • 第二层是一种组件外观 从公共存储中获取数据然后使用的服务 沙盒模式以协调智能组件的流程 在它下面。

    • 第三层基本上是智能组件层 协调来自哑组件的回调并与之通信 它自己的门面知道“全局”数据上下文。

    • 第四层是一个愚蠢的组件,仅知道其自身的输入和输出。

例如:

/data-stores:
 - user-hub.service.ts
 - user.service.ts
/pages:
 - user-profile-container.component.ts (smart-ass)
 - user-profile-container.service.ts (sandbox-facade that knows about data-stores)
/components:
 - bunch of dumb components that are unique in this module that only knows about user-profile-container
  1. 我的智能组件仅获得一个流,并且我到处都使用异步管道
  2. 所有数据都在Facade中进行管理,然后在业务流程中经过某种检查点后保存在数据存储中,以改善用户体验

我对我的想法的怀疑是,当我在数据存储级别上实现user-hub.service(websocket)时。我必须在某处订阅回调,以便调度数据更改。例如,其他人在社区应用程序中接受了好友请求,我们希望该请求显示在用户个人资料对象中的好友列表中。当有人点击API上的accept终结点时,我会通过websocket向其他人发送信息。由于数据存储区应该是数据的唯一所有者,我认为我应该在user-service.ts内部订阅回调。

我基本上在user-hub.service中创建了一个可观察到的friendRequestAccepted $,并在user.service.ts的构造函数中进行了订阅

最后是问题:

  1. 我听说订阅服务被认为是不好的做法。但是在我的体系结构中,我认为我不应该在智能组件中订阅websocket回调,因为它不是数据所有者。我还认为,可以在应用程序的任何数据存储中订阅某种全局事件以刷新所有数据可能会很有用。是否应该在服务中订阅webscoket回调?为什么?

  2. 我无法在服务中使用ngOnInit,并且听说在构造函数中进行订阅被视为不好的做法。因此,如果订阅服务还不错-我应该订阅哪一部分?在我阅读构造函数时,应该仅是数据分配方法,而不是回调寄存器方法。

谢谢您的任何建议,我是初学者!

0 个答案:

没有答案