.NET 基金会项目介绍-ReactiveUI

newbe36524

发布于 2020-03-16 11:00:38

2K0

发布于 2020-03-16 11:00:38

文章被收录于专栏：newbe36524的技术专栏newbe36524的技术专栏

ReactiveUI 是属于 .Net 基金会的一个项目，本文将简要介绍该项目相关的信息。

中文介绍

中文介绍内容翻译自英文介绍，主要采用意译、如与原文存在出入，请以原文为准。

ReactiveUI

ReactiveUI 是一个可用于所有 .Net 平台的可组合的 MVVM 框架，它受启发于“反应式编程”。“反应式编程”是一种编程范式。通过它，您可以通过高可读性的方式和抽象的可变状态来表达您的产品特性，而这些不强关联与用户界面，因而提高应用程序的可测性。

本项目是非常流行的 ReactiveCocoa 框架的父级项目。

内部的维护者们也会争论 ReactiveUI 到底是不是一个框架，因为其项目核心是一系列对 Reactive Extensions 的扩展。

我们相信，尽管代码运行在计算机上，但代码就是人与人之间的沟通。如果您的代码为他人的阅读进行过优化，那么时间久了之后，您的项目将会更好。软件应该容易被他人阅读，这是非常重要的。我们相信Reactive Extensions 的力量是让你能够以高可读性的方式来表达您的产品特性。

让我们举个例子。你现在有一个文本框。当用户输入一些内容时，你需要发送网络请求来获取输入关键词的搜索结果。你的设计师希望这个搜索操作是自动的，只要用户输入内容后就自动搜索。你的后端团队希望确保每次发起搜索时仅发送一次网络请求。在用户进行输入的时候每秒不要太高频的发送请求。

通常会如何实现呢？

今天，大多数的现代编程是基于命令式的，这意味着其基于传统的CPU处理循环来建模。CPU 会执行一个指令，然后获取下一个指令，然后执行，依次循环。数十年来,开发者们都不得不在建模时形如CPU的运行范式，至少从 1980 年初期开始，就一直如此。

当我们寄希望于应用程序的行为是正确的，而这种正确性是依赖于开发者的正确性。此时，我们很容易发现，我们正处于一个棘手的窘境中。我们可以尝试使用单元测试或集成测试等办法来减低命令式编程的出错成本，但假如有更好的办法，那为什么还降低成本呢，毕竟成本已经不存在了？

没错，确实有更好的办法！

很久以前，当计算机编程刚刚出现的时候，计算机程序不得不完全采用手动的方式编写。如果技术员按照正确的顺序输入了正确的机器指令，那么程序的结果将会正确地符合业务场景。想要告诉计算机如何进行操作，这本身就是容易出错的，并且这非常依赖于无懈可击程序员。但直接将“这个操作是什么”告知的计算机，然后等待结果产出，无需关心计算机如何处理，岂不美哉？

ReactiveUI 受启发于函数反应式编程的编程范式，这种方式使得开发者可以将用户输入建模为一个随时间变化的函数。这简直太棒了，它使得您可以从用户界面上抽象模型状态，基于这种方式您便可以将产品概念表达为更加可读的方式，换言之，这也将提高程序的可测试性。

初见反应式编程可能会觉得可怕而复杂，不过，这有一个好办法，理解反应式编程的最好方式是借助一个电子表格：

这里有三个单元格, A, B, 和 C
C 为 A 与 B 相加的和
无论 A 和 B 如何变化， C 都会自动的更新自己的数值

这就是反应式编程：输入的改动会自动的在系统中传递。

项目详情

笔者简评

可读性和可维护性是反应式编程带来的最为明显的好处。这点特别在业务代码上会有比较明确的体现。

理解的着重在于“命令式”和”定义式”的却别。就例如 SQL 是一种定义式的编程方式，其没有告诉计算机如何循环，只需要定义需要获取的内容即可。至于如何解析数据、命中索引、处理冲突这些都有数据库引擎自己处理。从可读性上考虑， SQL 的可读性较自己写命令循环更具备可读性。

同样地，“反应式”也可以理解为是一种“定义式”的风格。

更加深入的内容，可以了解核心项目： Reactive Extensions for .NET

英文介绍

ReactiveUI

ReactiveUI is a composable, cross-platform model-view-viewmodel framework for all .NET platforms that is inspired by functional reactive programming which is a paradigm that allows you to express the idea around a feature in one readable place, abstract mutable state away from your user interfaces and improve improve the testability of your application.

It is the father of the extremely popular ReactiveCocoa framework. Internally the maintainers debate whether ReactiveUI is or is not a framework, as at its core the project is essentially a bunch of extension methods for the Reactive Extensions.

We believe that code is communication between people, that also happens to run on a computer. If you optimise for humans, then over a long time your project will end up better. Software should be understandable by other people; that is super important. We believe that only the power of the Reactive Extensions allows you to express the idea around a feature in one readable place.

Let’s say you have a text field, and whenever the user types something into it, you want to make a network request which searches for that query. Your designer has requested that this search query automatically execute as the user is typing but your operation team wants guarantees that only one network request is ever in transit and no more frequently than roughly once per second whilst the user is typing.

How would you usually implement this?

Most modern programming today is basically imperative, meaning it models the traditional fetch-execute cycle of a CPU. Perform an instruction, fetch the next one. Perform that one, and so on. For decades, programmers have had to mould their brains to fit the paradigm of the CPU. It’s been like this since the early 1980s.

When we rely on hoping that the behavior that emerges from a program is correct, and that reliance is based on nothing more than a programmer’s correctness, then we can easily find ourselves in a sticky situation. We can try and mitigate the costs of imperative programming with things like unit tests or integration tests, but why mitigate the costs when there’s a better way?

There is a better way

Long ago, when computer programming first came to be, machines had to be programmed quite manually. If the technician entered the correct sequence of machine codes in the correct order, then the resulting program behavior would satisfy the business requirements. Instead of telling a computer how to do its job, which error-prone and relies too heavily on the infallibility of the programmer, why don’t we just tell it what it’s job is and let it figure the rest out?

ReactiveUI is inspired by the paradigm of Functional Reactive Programming, which allows you to model user input as a function that changes over time. This is super cool because it allows you to abstract mutable state away from your user interfaces and express the idea around a feature in one readable place whilst improving application testability. Reactive programming can look scary and complex at first glance, but the best way to describe reactive programming is to think of a spreadsheet: