Ngrx 相对于 Observable Data Services 架构的优势？ [关闭]

Posted 2023-02-22

【中文标题】Ngrx 相对于 Observable Data Services 架构的优势？ [关闭]

【英文标题】：Ngrx advantages over Observable Data Services architecture? [closed]

【发布时间】：2019-05-16 04:01:06

【问题描述】：

observable data service 和 Ngrx store 都为 Angular 应用程序提供了基于 Store 的解决方案。

Ngrx 使用 Flux 设计模式并且需要一个 3rd 方库，而 Observable 数据服务可以使用 angular 和 rxjs 的内置特性来实现，并且在某种程度上我猜它本身就是一个 Angular 设计模式。

有关 Observable Data Service 架构的信息可以找到here

我读过他的文章：Redux, RxJs and Ngrx Store - When to Use a Store And Why? 真正了解基于存储的解决方案旨在解决的主要问题是什么，以及我认为它们都解决了这些主要问题的方式：

解决了由于多个参与者同时更改相同数据而发生的 Facebook 计数器问题 当只有底部/顶部真正需要输入方式时，将输入方式向下/向上移动组件树时的“无关道具问题”（对所有阻碍的组件都没用 - 破坏 SRP）

我看到使用 Ngrx 时的成本 - 包大小更大，大量样板代码 - 对于一个简单的功能需要更改多个文件并实现一个动作，一个减速器，如果使用 ngrx 副作用，那么还有一个加载器动作和错误操作.. 理解这个概念和通量工作方式的学习曲线比我猜的可观察数据服务要大..

然而，一个优点是它提供了很棒的开发工具。

所以问题如标题所述： Ngrx 相对于 Observable Data Services 架构的优势？

一个简单的 Todos 可观察数据服务存储示例：

 @Injectable()
    export class TodoStore 

    private _todos: BehaviorSubject<List<Todo>> = new BehaviorSubject(List([]));

    constructor(private todoBackendService: TodoBackendService) 
        this.loadInitialData();
    

    get todos() 
        return asObservable(this._todos);
    

    loadInitialData() 
        this.todoBackendService.getAllTodos()
            .subscribe(
                res => 
                    let todos = (<Object[]>res.json()).map((todo: any) =>
                        new Todo(id:todo.id, description:todo.description,completed: todo.completed));

                    this._todos.next(List(todos));
                ,
                err => console.log("Error retrieving Todos")
            );

    

    addTodo(newTodo:Todo):Observable 

        let obs = this.todoBackendService.saveTodo(newTodo);

        obs.subscribe(
                res => 
                    this._todos.next(this._todos.getValue().push(newTodo));
                );

        return obs;
    

    toggleTodo(toggled:Todo): Observable 
        let obs: Observable = this.todoBackendService.toggleTodo(toggled);

        obs.subscribe(
            res => 
                let todos = this._todos.getValue();
                let index = todos.findIndex((todo: Todo) => todo.id === toggled.id);
                let todo:Todo = todos.get(index);
                this._todos.next(todos.set(index, new Todo(id:toggled.id, description:toggled.description, completed:!toggled.completed) ));
            
        );

        return obs;
    


    deleteTodo(deleted:Todo): Observable 
        let obs: Observable = this.todoBackendService.deleteTodo(deleted);

        obs.subscribe(
                res => 
                    let todos: List<Todo> = this._todos.getValue();
                    let index = todos.findIndex((todo) => todo.id === deleted.id);
                    this._todos.next(todos.delete(index));

                
            );

        return obs;
    

【问题讨论】：

你有什么问题？

如标题所述 - 与 Observable Data 服务相比，使用 Ngrx 有哪些优势..

您在询问优点/缺点，这意味着您在询问意见（无论您是否认为），这与 SO 无关。你似乎喜欢 Observable Data Services（我的观点），所以就这样吧。在某个时候尝试 ngrx，然后形成你自己的观点。然后你就可以选择适合你的应用程序了。

@R.Richards 我同意我征求意见 - 我想听听其他人的想法以及他们如何支持 Ngrx，这可以帮助我做出最佳的架构决策，问这些是否不合适问题类型？

就 SO 征求意见被认为是题外话。它只是打开了辩论的大门，而不是帮助某人解决编程问题。这是其中一个主题，取决于一个人，可能会产生许多不同的答案。

【参考方案1】：

一目了然的区别：

一个存储所有状态。您的示例看起来每种数据都有一个：待办事项、事件、联系人等。如果您只有一种数据，那么 NgRx 可能会过大。

时间旅行调试。喜欢这个功能！

您可以谷歌benefits of ngrx 并查看更多回复。

【讨论】：

是的，在我的示例中，我的应用程序中的每个域模型都有一个商店 - 与具有每个应用程序域模型（或至少大部分时间）的状态的 ngrx 相同，让我们说我的应用程序有多种数据 - 为什么所有州的单一商店是一个优势？关于调试我完全同意

团队中的每个人都知道获取数据的唯一一个地方。

我看不出区分数据来自何处的区别，因为在 Observable Data Services 的情况下：团队需要知道哪个服务拥有数据，而在 Ngrx 的情况下，团队需要知道哪个state 有数据（换句话说，要使用哪个选择器），因此我认为在这方面没有优势..

“酷调试工具”的大量样板，是的。

这也可能有用：youtube.com/watch?v=omnwu_etHTY NgRx 的一位开发人员的“你可能不需要 NgRx”的谈话。