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 都會自動的更新自己的數值

這就是反應式編程：輸入的改動會自動的在系統中傳遞。

項目詳情

• 官方網站

• 項目源碼

• 項目許可證:?MIT

• NuGet

• 項目聯系人

相關鏈接

• Slack 聊天室

• Meetup 會議

• 參與貢獻

• 開發文檔

• StackOverflow

筆者簡評

可讀性和可維護性是反應式編程帶來的最為明顯的好處。這點特別在業務代碼上會有比較明確的體現。

理解的著重在于 “命令式” 和” 定義式” 的卻別。就例如 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:

• Three cells, A, B, and C.

• C is defined as the sum of A and B.

• Whenever A or B changes, C reacts to update itself.

That's reactive programming: changes propagate throughout a system automatically. Welcome to the peanut butter and jelly of programming paradigms.

Project Details

• Website

• Source

• License:?MIT

• NuGet

• Project Leads

Quicklinks

• Slack

• Meetup

• Contribute

• Documentation

• StackOverflow

以上《英文介紹》摘錄自 .NET Foundation 的項目介紹?。原文受原項目許可證保護。

總結

以上是生活随笔為你收集整理的.NET 基金会项目介绍 - ReactiveUI的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。