整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
要
單選按鈕控件(RadioButton控件)為用戶提供由兩個或多個互斥選項組成的選項集。當用戶選中某單選按鈕時，同一組中的其他單選按鈕不能同時選定。
正文
當用戶選擇一個選項按鈕 (也稱為組中的單選按鈕) 時，其他人會自動清除。 給定容器中的所有 RadioButton 控件（如 a Form）構成組。 若要在一個窗體上創建多個組，請將每個組放置在其自己的容器中，例如或GroupBoxPanel控件。
RadioButton 控件 CheckBox 具有類似的功能：他們提供用戶可以選擇或清除的選項。 區別在于可以同時選擇多個 CheckBox 控件，但選項按鈕互斥。
屬性
CheckAlign | 獲取或設置 RadioButton 的復選框部分的位置。 |
Checked | 獲取或設置一個值，該值指示是否已選中控件。 |
方法
BringToFront() | 將控件帶到 Z 順序的前面。 |
Focus() | 為控件設置輸入焦點。 |
Hide() | 對用戶隱藏控件。 |
Show() | 向用戶顯示控件。 |
事件
CheckedChanged | 當 Checked 屬性的值更改時發生。 |
Click | 在單擊控件時發生。 |
一個例子
在窗體上添加3個RadioButton，點擊時在窗口顯示選中的RadionButton 文本。
private void radioButton1_CheckedChanged(object sender, EventArgs e)
{
this.Text=((RadioButton)sender).Text;
}這里有一個操作，就是將3個RadioButton的CheckedChanged事件同時綁定到一個后臺事件上。
修改一下界面，我們添加一個GroupBox容器，在窗口中添加三個RadionButton，你會發現這三個與先前的三個不在一組中。
我們新增一個Button，點擊判斷groupBox1中誰被選中了。
絡收音機這個名字在很多人眼里可能只是一類軟件的名字，但以前它也曾經有另一種定義：一種基于網絡的音樂播放器，它無須自備 CD 、卡帶、存儲卡等音樂載體，直接通過網絡接收音樂。這種方式與收音機有點類似，而且那時候音樂網站并不多，實際上收聽的內容也是以各個電臺的網絡直播為主，并且很多產品自己也直接命名為收音機，比如 Roku 公司的 SoundBridge Radio 系列和羅技的 Squeezebox Radio ，所以這類播放器就被叫做網絡收音機了。
這類產品出現至少已經有10年以上的歷史，天龍、安橋、雅馬哈、曼哈卡頓、 SONY 、先鋒、 BOSE 等等很多老牌音響廠商都有生產，但國內一直并不紅火。但這兩年“智能設備”風潮井噴式爆發，也順帶著連這類產品一起炒紅了，但操作面板被移植到了手機、平板上，并有了更加新潮的名字：智能 WiFi 音箱。這次體驗的 SUGR 方糖音箱就是這樣的一款產品，也是我遇到設計最另類的一款音響產品。
一、開箱及外觀介紹
方糖采用了現在主流的簡約包裝方式，綠色的紙套上僅有一個 SUGR Cube 的品名及一個極具蘋果風格的圓角正方形圖標。
取掉紙套后才是真正的包裝盒，同樣的簡約風格，類似首飾盒的斜向開蓋。
開蓋后就能看到 SUGR 立在里面，四周都有泡沫防護很是安全，音箱底下的小盒子里放著電源等配件。
方方正正一小塊確實與方糖這個名字很契合，前面板造型與紙套上的圖標長的一模一樣，看不到任何開關或按鈕，這種簡約的外形設計很是討喜。
方糖的體積僅有 104*104*108 ，實測重量 596g ，與2個月大的小貓放在一起都顯得很小，算得上小巧輕便，內置 6000mAh 電池可提供7小時的播放時間。與傳統音箱最大的區別在于它還有 1G 的 x-brust CPU 、 4GB 閃存和 WiFi 支持。音頻方面則是 4W 的輸出功率和3寸全頻揚聲器，并沒有提供頻率范圍參數。
方糖的背后則為塑料質地，正中間是音量旋鈕兼電源開關，旋鈕上那個扁長小孔是指示燈。旋鈕上方的小孔是麥克風，下方大孔則是倒相管，可增加音箱的低頻量，右下角則是 Micro-USB 充電孔和 Reset 孔。需要注意的是雖然方糖使用 Micro-USB 接口，但它所需的充電電壓是 12V 1A，并不能直接用普通 USB 充電器給它充電。
雖然方糖外觀上有著漂亮的原木紋理，但實際上它并非原木箱體，而是貼的一層原木木皮。原木木皮是用天然木材旋切出來的一層約 0.5mm 的薄片，所以有著天然木材的觸感和紋理。這是音箱和家具都普遍采用的一種方式，比如上圖背景就是我的電腦桌，貼的樺木木皮，色彩和我這個方糖用的北美白楓很接近。
方糖的底部則是一片橡膠，起到避震和防滑的作用。從橡膠上下露出的部分可以看到木皮接縫的地方。
從揚聲器周圍一圈的板材截面紋理也可以明顯看出，方糖的前面板并非原木而是密度板。 Kickstarter 網站的 Sugr Cube 介紹頁面也寫明了箱體采用 9mm 中密度纖維板( MDF )制造。
這問題我也問了很多朋友，多數妹紙表示看不出來，覺得方糖的木質造型很漂亮，但多數男性朋友一眼看出了問題所在：直接原木打造不可能一圈連貫的順紋，總要有橫截面才對。
方糖附帶的充電器挺讓人驚喜，居然采用了高通 QuickCharge2.0 快速充電器，插頭則是拆卸式，遺憾的是只附帶了國標插頭，附帶的 USB 線很粗但很柔軟。
這個充電器支持 100-240V 全球電壓，高通 QuickCharge2.0 快充規格也支持 5V 、 9V 、 12V 幾種輸出，能根據手機自動判斷充電電壓，所以這個充電器也能用來給平板和手機充電，出行就可以少帶個充電器了。
拆卸式插頭組裝后體積會偏大，但也能通過換插頭支持全球使用，只是插頭不大好買，要方糖能附贈多個插頭就好了。
功率計實測方糖充電功率為 11.3W ，估算充電效率及方糖的電池容量，充滿電大概需要1.3小時左右。
外觀介紹就到這里，下面開始操作及功能說明。
二、操作及功能說明
現在音箱的操作方式越來越多了，比如京東和科大訊飛合作推出的 Dingdong 就加入了語音控制功能，全身沒有按鈕的方糖當然也要有自己獨有的操作方式。
方糖采用了特殊的“體感”操作方式，輕拍音箱頂部就能開始播放音樂或暫停。
向左或向右傾斜則能切換上下曲目，這也就意味著要擺放在比較空的地方才有操作空間。
未來還能設計更多的操作方式，比如在 Kickstarter 站的介紹里就有長按頂部分享音樂的操作，以后國內可能也會有一按微博或朋友圈的選項呢。
體感操作很好玩，但是也給我造成一定困擾，我家的貓太喜歡去踩它了。。。
當然主要操作方式還是依賴手機，畢竟選曲、選功能只有手機App 上才能設置。方糖說明書上的安卓 App 居然掃碼直接找不到頁面，因此本次測試都是在 iOS 下進行的。
方糖音箱目前主要有六大功能：放松音樂、收音機、 RANDORA 、荔枝 FM 、豆瓣 FM 、本地音樂，但方糖的系統是可更新的，只要合作方增加以后資源也會更多，比如百度音樂、 QQ 音樂等將來都有可能進駐。
方糖目前的前三個功能都不大具有實用性，我就一句話帶過了,后面主要介紹后三個主要功能。
放松音樂：內置的雨聲、海浪聲、鳥叫聲等，但是這些聲音都太短，并且兩次循環中間會有那么一秒無聲。
收音機：主要是 BBC 等國外電臺，連接不大穩定，并非帶寬問題，1 00M 電信光纖依舊經常卡。
PANDORA ：僅允許美國、澳大利亞和新西蘭的IP訪問，國內 IP 無法使用。
荔枝 FM 的音樂內容并不突出，但相聲、評書、脫口秀、有聲小說等方面的資源特別多。方糖聽荔枝 FM 非常流暢，音質也很好，缺點是沒有搜索也不能收藏，每次只能從榜單或分類里慢慢找。
豆瓣 FM 也有著不能搜索的問題，雖然增加了收藏功能，但賬號不知何故無法登陸，所以也只有直接從列表里選。
方糖內置的 4GB 存儲空間可以存放不少的音樂文件，因此最后一個功能目前來說是最實用的。音樂文件可以直接從手機傳送進去，電腦則要用瀏覽器訪問方糖的 IP ，從專用頁面來上傳。除了常見的 MP3 外，方糖還支持 WAV 、 APE 等多種無損格式，因此這個方式也能獲得最好的音質。但這個功能還是有類似前面的問題，它只能按順序播放里面的所有音樂，不支持自建播放列表或分類，也不能對音樂文件進行排序，因此不能隨心情隨意調用不同類型的音樂。
除了幾個主要功能外，方糖還附帶了鬧鐘、煲機和濾鏡的功能。但濾鏡暫時還是空的，鬧鐘不能選擇音樂，只有 iPhone 的鬧鐘聲音一種，只有煲機的實用性較高。本文后面的音質測試部分都是在煲機超過15小時候進行的。
除了作為網絡音樂播放器外，方糖還提供了 AirPlay 功能，以后通過軟件升級，方糖也可能會支 持DLNA 、 UPnP 等無線模式。 iPhone 、 iPad 、蘋果電腦等都能通過 AirPlay 直接把聲音通過 WiFi 傳送給方糖。 PC 安裝 iTunes 后也可以通過 AirPlay 用方糖來播放音樂，但其它軟件就不支持了。
有了 AirPlay 的支持，用 iPad 玩游戲、看電影、聽音樂就不再局限于內置喇叭了，外接音箱的效果會好的多。但實測發現看視頻時候會有聲畫不同步的情況，希望下一次系統升級能解決這個問題。
三、音質主觀測試
當我在官網和 Kickstarter 看到這張頻譜曲線的時候是很震驚的，這圖完全不像是一個全頻帶音箱，而是2.1音箱中的衛星箱。從頻譜曲線看來方糖的高頻整體略為提升， 2K - 8K 一段比較平直， 8K-11K 段更加提升，一直到 20K 都沒有跌落。從這一部分來看方糖語音的清晰、明亮度表現應該不錯，高音的層次和色彩以及泛音都應該挺好。
但看低音段就非常奇怪了，通常小尺寸全頻帶音箱的低音截止頻率會設定在 80-100Hz ，因為 80Hz 以下的低頻不是小尺寸音箱能駕馭的，駕馭不好反而影響效果，而 80-160Hz 這一段是極為重要的低音基音區，聲音的厚實感主要就來自這里，量不足則音色會表現的很無力，方糖居然從大約 150Hz 開始就迅速跌落，這是要放棄低音？還是準備再出一個配套的低音炮？
通常我們都不會拿耳機和音箱做比較，但方糖的頻譜曲線實在太奇怪了，而我又沒有全頻段表現良好的大尺寸音箱作為比較，所以就動用了森海 HD598 ，這個耳機在 60 - 300Hz 之間還是非常平直的。
順便我還用 BOSE 的 SOUNLINK mini 做為對比參考， BOSE 在小體積音箱上的低音量感上無人能及，而高音方面則相對保守，可以說跟方糖是完全相反的設計。
測試曲目主要是惠威2010年的試音碟和雨果發燒碟一，全部采用 WAVE 格式，方糖直接播放內存中的音樂文件，而 BOSE 和 HD598 均用 iPhone5C 。選擇雨果發燒碟一主要是因為它提供了從 25Hz 到 20KHz 近30個頻率點的測試信號，剛好可以用來驗證方糖的頻率范圍。
低音范圍測試：
我用 250Hz 測試信號把方糖、 BOSE 和 HD598 都調到聽感上基本一致的音量，然后從高到低試聽各個設備的回放效果， HD598 作為參考標準。
方糖 200Hz 時還基本與 HD598 保持一致，到 160Hz 就已經明顯低于 HD598 了，到 100Hz 已經非常微弱， 63Hz 完全聽不到了，這一結果基本與官網公布頻譜曲線吻合。
BOSE 一直到 160Hz 都基本與 HD598 都保持一致， 125Hz 和 100Hz 兩個點則明顯高于 HD598 ，到 63Hz 還量感十足， 56Hz 則完全聽不到了。
這一測試中我還發現方糖的底噪表現明顯優于藍牙連接的 BOSE ，正常聽音距離下聽不到電流聲，只有貼著耳朵才能聽到。
音質主觀測試：
從前面的測試可以看出方糖是個極為偏食的音箱，但測試中我還是選擇多范圍的音樂進行比較。小提琴《梁祝》：小提琴的頻率范圍是方糖可以完美掌控的，在小提琴的音色、泛音、空間感方面方糖要明顯優于 BOSE ，但是在曲子始末的合奏部分方糖則明顯吃虧，鼓聲和大提琴的聲音損失了太多細節。鋼琴協奏曲《黃河》：音域極光的鋼琴顯然不是方糖的菜，雖然方糖的節奏、清晰度都明顯優于 BOSE ，但低音細節損失過多，氣場差太遠了。《女聲清唱-試音方程式》：人聲方面方糖表現極好，明快干凈的聲音遠遠強于 BOSE ，在聽荔枝 FM 上聽各種脫口秀、相聲、有聲小說等內容，方糖的表現都非常好。
四、體驗總結
方糖算是我體驗過非常另類的音箱，它有著小巧的外形和特別的操作方式，原木質感的外觀也很漂亮，放在床頭或茶幾上是個挺不錯的裝飾品。它的聲音干凈清爽，但低頻缺失的問題會讓它非常偏食，這似乎并不符合現在的主流方向，否則主打低音的 BOSE SOUNLINK mini 也不會這么紅了。方糖的 App 界面同樣干凈清爽，但播放列表、搜索這些基礎功能還是應該加上，否則實在有點影響使用。
語：本文基于作者虛構的“幼兒園健康上報系統”，演示如何用低代碼平臺快速搭建一套應用系統，并介紹演示了國內外的一些知名aPaaS產品，如Mendix、Outsystems、宜搭、明道云，試圖探討低代碼平臺在產品設計上的核心本質，從而讓大家對低代碼有一個更直觀的理解。
在案例開始之前，我們先聊聊基本概念。
低代碼平臺是繼中臺之后又一個火爆的話題，實際上低代碼本身并不是一個新穎的話題，也不是最近才有的技術突破和創新，而是存在了十幾二十年的概念。早期的大型管理軟件套件，都有類似于可拖拽式的快速開發平臺，方便技術人員不用寫代碼，快速實現某些基礎功能。
低代碼雖然現在習慣被稱作aPaaS，好像看起來是一種PaaS，顯得和SaaS有密切關系，但大家需要認識到，低代碼開發平臺并不是因為SaaS才有的概念，而是遠古時期就已經存在了的。
簡單來講，低代碼平臺是一套期望通過拖拽配置，就能實現一套業務型軟件系統的開發平臺，并能無縫的部署上線運行。在這個過程中，當然也允許編寫部分代碼，但更重要的是，大量基礎性的編碼工作，都可以被低代碼平臺快速的自動化實現。
低代碼的第一個應用場景，是為了幫助成熟的軟件產品，低成本的支持個性化需求，提高開發速度，甚至做到拓展客群。
例如，很多成熟商業軟件（包括私有化部署的商業軟件套件以及SaaS形式的產品），期望通過低代碼平臺的建設，加強產品擴展能力，更好、更快的服務客戶，以及與 ISV協作，將產品的目標客群拓展到更廣泛的領域和行業。
在這種情況下，低代碼平臺是低成本高效解決個性化需求終極方案。此時，低代碼的目標用戶可能包括工程師、實施顧問。國外的SAP、Oracle、SalesForce，國內的用友、金蝶、北森、銷售易等，都有基于自身軟件產品作為基礎核心的低代碼解決方案。
低代碼第二個應用場景，是為了幫助甲方企業，低成本快速搭建全新的應用系統，尤其是讓不懂編程的業務人員也能自主實現，從而讓企業以更低的成本享受數字化技術賦能業務的好處。
實際上，在企業中大量的應用系統都是流程型的，對于邏輯相對簡單，流程鏈條并不復雜的業務場景，找套裝軟件支持大材小用，找外包開發獨立系統成本又高，那么低代碼平臺可能是一個不錯的選擇。此時，低代碼平臺的目標用戶可能包括甲方企業的業務人員，或者IT人員。
國外的OutSystems、Mendix，國內的明道云、氚云，都屬于這種情況。需要留意的是，目前國內有些做報表平臺、流程引擎的廠商，為了蹭熱度，也都稱自己是低代碼平臺。嚴格來講，這些廠商提供的產品能力，只是完整低代碼平臺所需具備能力的子集，并不能算低代碼產品。
說了這么多概念，想必大家對低代碼的印象依然比較模糊。接下來，我將通過一個案例，帶著大家去體驗一款低代碼產品的使用。開始之前，還有幾個問題需要和大家強調：
好了，接下來，讓我們進入案例。
李校長是小豚鼠幼兒園的校長，最近她遇到了一個煩心事，根據教委統一要求，疫情期間，需要家長每天上報小朋友的健康狀況，學校統一管理，但是教委又沒有提供統一的技術支持。
為了實現這個訴求，幼兒園的老師們想盡辦法，比如說用微信群管理，或者在線文檔管理，但都不是很方便，例如無法做實時統計，數據容易被誤操作。而如果找一個軟件公司來幫忙做一個小系統，居然要花三四萬元，對于一個幼兒園，這可是一筆不小的開銷。
李校長的侄子小王是一名B端產品經理，在閑聊中得知了李校長的難題，心思一動，問道：
小王：姑姑，您說的這事兒，或許我能幫上忙，做一套軟件系統，就可以很好地解決您的問題！
李校長：真的嗎，那太好了，但是我們沒有很多預算啊！
小王：不用花您一分錢，我幫您免費做，不過我想先了解下您對這個業務管理的訴求和期望。
李校長：多謝啊！我的訴求很簡單，就是讓家長們每天打卡，如果有健康異常的情況，我能第一時間收到提醒，還能讓老師們去跟進，看看到底啥問題。另外，就是最好能有一些實時報表，讓我看到最新的健康上報情況。
小王：得嘞，我了解了，這事兒交給我了，我幫您設計一套操作的流程，和支撐的系統，免費給您用！
了解了大概的背景后，小王開始構思這套給小豚鼠幼兒園使用的幼兒健康上報系統的設計方案。
李校長：太棒啦，期待！
小王了解完基本需求后，開始構思這套系統該如何設計。首先整理下這套系統涉及到的利益方，分別如下：
雖然業務本身過程很簡單，但因為畢竟是一套從無到有搭建的管理系統，有些基礎數據準備工作需要完成。小王思考了一會兒后，繪制出了一份簡明的業務流程圖，如下。
可以看到，期望家長能打卡，有些基礎數據要先維護好，根據常識，需要維護包括班級信息、學生信息，而打卡動作是針對學生的，因此要對學生關聯打卡信息。
另外需求中提到了，如果打卡體溫異常，需要有老師跟進，我們考慮生成一個待辦任務分配給老師，這條待辦任務關聯在異常的打卡記錄上。對業務有了以上分析和思考，我們可以繪制出業務背后的ER模型圖（領域模型），如下圖。
每名老師可以管理多個班級，每個班級只能有一名老師管理。每個班級可以有多個學生，每名學生有多個健康上報記錄（打卡記錄），每個健康上報記錄可以產生一條體溫異常跟蹤記錄。
這些抽象出來的實體，是我們要設計的這套健康上報系統的核心，因為打卡（健康上報）的過程，實際上就是對這些實體數據做增刪改查而已。
接下來，我們基于流程圖，來思考系統落地執行的頁面流轉圖：
除了這些頁面級別的操作需求，還有一些業務規則需求，例如：如果健康上報體溫異常，自動生成一條待跟進任務，發送給該學生班主任，并推送消息給校長。
總之，我們會發現，涉及到業務運作的功能頁面，主要就是ER實體的列表頁、詳情頁（創建編輯），并且，不同的用戶對不同頁面以及不同的數據具有不同的權限。
經過整理分析，我們可以列示出系統涉及到的相關頁面，以及權限表如下（此處僅僅是簡單示意，后邊在明道云中我們會展示更加全面詳細的權限設計，包括數據權限的管理設計方案）：
經過以上分析，雖然細節還不完備，但我們對“幼兒園健康上報系統”的設計思路已經了然于胸，接下來，我們直接進入低代碼平臺的開發演示環節！
首先，我們來到明道云工作臺，點擊“添加應用”，創建新應用“小豚鼠幼兒園”（已經在下圖中）。
接著，我們針對ER模型中的四個實體，分別創建工作表，下圖所示是創建班級實體的工作表編輯頁面。
工作表是明道云的概念，所謂工作表，實際上對應著ER建模中的實體，工作表中的相關控件，定義了實體的字段。例如班級表單中定義了自增長的“班級ID”，字符串類型的字段“班級名稱”，枚舉字段“狀態”等。
通過表單來呈現出實體，是一種容易讓人理解的設計方式。而實體背后的本質，是所謂的“對象”，以及最終會轉移成數據庫的表。在有些低代碼平臺中，則通過對象編輯器來定義管理實體，這是一種靈活性更強，但用起來更復雜的方案，在后文我們還會進一步介紹。
不論是表單編輯器，還是對象編輯器，原理是一樣的，管理的都是提煉出的實體。對于非技術人員來講，表單可能更容易理解接受一些。
在班級表單中，有一個“學生”的控件，是一種關聯記錄組件。因為班級和學生是一對多關系，每個班級可以擁有多個學生，所以在班級表單中，我們允許看到關聯在班級下的所有學生列表，這在B端產品交互中是非常常見的一種設計形態。
實體之間所謂一對多、多對多的關系，體現的是多個表之間的關聯，在設計器中可以輕松地定義班級和學生的一對多關系，如下圖：
實現了關聯后，表單和表單之間建立了連接，在詳情頁（單條表單數據的呈現頁面）展現上，也都會完美的自動完成。例如：下圖是針對某一條班級數據的詳情頁（PC版本）：
aPaaS平臺都會自動完成PC版本和移動版本的適配，并且格式都是可調整的。例如上圖呈現的是PC版的班級詳情頁，下圖則是移動版本：
接下來，我們依次完成“學生”、“健康上報”、“體溫異常跟蹤”三個實體的表單配置。
下圖中，橫排的“校園管理”、“校長控制臺”，可以理解成我們針對系統配置的一級導航，豎排的四張表單，表示歸屬于某個一級導航，而每個表單在右側主區域配置的列表視圖，就是二級導航菜單，如下圖針對班級的表單，定義了“全部”、“生效中的班級”、“已畢業的班級”、“我的”四個列表視圖，也即“校園管理”一級菜單下的四個二級菜單。
那么，什么是列表視圖呢？
工作表只是定義了實體的具體字段，如何將實體的列表數據呈現出來呢？例如，如何將“班級”列表數據以不同的展現形式呈現出來呢？這就需要視圖編輯器了！
在視圖編輯器中，可以定義實體對應的多條數據的列表化呈現，包括列表數據默認的篩選條件，默認的展示字段，默認的字段排序，都可以輕松定制，如上圖所示。
在大多數自研的B端產品中，列表頁（也就是視圖）是最常見的功能頁面，而一般情況下，這類頁面都是硬編碼實現，而非通過類似于視圖編輯器這樣的前端組件實現。在成熟的軟件產品中，已經沒有列表頁的概念，都會通過視圖編輯器來處理，這樣就大量的簡化編碼工作。
如下圖，我們針對“班級”表單，定義了四個視圖，分別是“全部”、“生效中班級”、“已畢業班級”、“我的”，其中截圖呈現的是針對“生效中班級”視圖的默認搜索條件配置，可以看到，我們設置了該視圖默認查詢條件，是“狀態”字段為“教學中”的所有班級數據。
我們先前提到，在“班級”表單中建立了和“學生”記錄的一對多關系，在“學生”表單中，同樣需要有一個字段，關聯了“班級”表單的“班級ID”字段，從而完成一對多關系的定義。
但是，如果我們希望在學生表單中呈現出所在班級的名稱，以及在學生視圖中呈現出所在班級的字段，該如何實現呢？
因為在建立一對多關系式，我們只是定義了ID之間的聯系，所以，如果想在“學生”表單中呈現“班級”名稱，必須做一個變量引入的特殊處理，在明道云中，采用了一種叫做“他表字段”的設計方式，簡單講，就是把關聯表的某個字段引入過來，進行展現，如下圖：
下邊的紅框，定義了ID之間的關聯，上邊的紅框，引入了“班級”表的“名稱”字段，以便在“學生”表單和視圖中展現。
在其他低代碼產品中，針對這類訴求的解決方案不太相同。
嚴格來講，表單只是數據對象的外化呈現，根據軟件設計MVC的分層理念，數據定義和前端呈現要分層隔離，對象編輯器嚴格定義了數據實體本身，而如果在表單或視圖中需要做多表連接去呈現其他相關表的某些字段，則是可視化層面需要解決的問題。
因此，在很多更復雜一些的低代碼產品中，所有可視化的部分，都是基于頁面編輯器來完成，和底層數據定義是互相獨立的兩件事。因為明道云的產品，為了在很大程度上降低用戶的學習成本，所以將數據底層的對象編輯器，和展示層的表單編輯器融合在一起了。
現在，我們來解決一個棘手的問題。如果我們希望在學生視圖中，呈現出該學生的老師姓名，該如何做到呢？通過學生，可以找到所在班級，但是，負責班級的老師是誰呢？如何定義呢？
一種做法，是針對“班級”表單增加一個字段，可以關聯老師的賬號，完成老師和班級的關系映射。在明道云，我們采用了另一種取巧的方式，需要由校長，將每一條班級數據的擁有者，修改成具體的老師賬號，如下圖，圖中“王老師”，是一名角色為“老師”的獨立用戶。
通過這個動作，實現了對班級負責老師的分配。接下來，再利用前邊提到過的“他表字段”功能，將這個字段值引入其他表單對象中。
如此一來，所有針對某個班級下邊關聯的學生，以及針對學生關聯的健康上報記錄，我們就都可以追溯到所負責的老師了，這對下一個需求的實現至關重要！
我們回憶下，現前有這樣一條需求：如果健康上報體溫異常，自動生成一條待跟進任務，發送給該學生班主任，并推送消息給校長。
這個需求該如何實現呢？這就用到了aPaaS平臺中非常核心且重要的流程編輯器功能，可以說流程編輯器是低代碼平臺的靈魂！
將上述需求，進一步準確描述：如果新增或編輯“健康上報”表單數據時，其中的“體溫是否正常”字段選擇了“否”，則自動生成一條狀態為“待跟進”的“體溫異常跟蹤”數據，并發送消息給校長，以及該學生的老師。
在低代碼平臺中，通過流程編輯器，來實現類似于以上這類帶有自動化觸發執行，以及多表數據自動更新的功能。我們來到流程編輯器，創建“異常體溫上報觸發跟進任務記錄”流程，如下圖：
在圖中，我們設計了三個流程節點。
由工作流創建的數據，創建者字段顯示為工作流，如下圖：
流程編輯器，不是簡單地工作流引擎，我們一般理解的工作流引擎，例如審批流，只是針對單一數據對象的多節點處理。而真正復雜的流程編輯器BPM，需要在流程中對不同數據實體進行復雜處理，這也是很多B端業務的核心處理邏輯和過程。
當然明道云的流程編輯器功能很多，如下圖，我們不再贅述。
截止現在，還有個核心功能，我們沒有實現，家長如何上報數據？
一種辦法，是針對每個家長開通一個賬號，賬號和學生做關聯，家長登錄系統，提交表單時默認會提交相關學生的“健康上報”記錄。
另一種辦法，是將“健康上報”的表單公開出去，任何人都可以提交，這樣做的好處是不需一個一個維護家長賬號，壞處是因為系統無法識別提交人和對應的兒童，需要提交人手工從學生清單中選擇學生，操作比較繁瑣。
如下圖，我們將表單設置了公開鏈接。
走到這一步，涉及到業務流程的核心功能和數據表單都開發完畢了，接下來，我們需要給李校長配置她的管理工作臺，也就是dashboard。通過類似報表引擎的功能，配置出校長的監控儀表盤，我們將其放在“校長控制臺”的一級導航下邊，如下圖：
該功能的使用，和經典的報表引擎相通，不再贅述。
最后，我們進行角色、權限的設置。我們設置了兩個角色，“校長”和“老師”。
B端產品的權限管理包括兩部分，功能權限決定了用戶可以訪問哪些菜單，操作哪些按鈕，數據權限決定了用戶可以訪問操作的數據集合范圍是什么，一般通過組織機構樹來實現。
下圖是明道云的數據權限配置管理全貌：
可以看到，每個針對每個角色，設計不同表單視圖的查看、編輯權限，這是功能權限。
點擊每個表單最后的設置按鈕，還可以定義角色針對表單的數據權限，包括是否允許處理所有數據，抑或是本人和下屬的數據，抑或是本人擁有的數據（記得前面案例中我們對班級的“擁有者”進行了調整么），抑或是本人創建的數據。
甚至還可以針對具體的字段設置更精細化的權限，如上圖左下角窗口所示意。
完成以上配置，我們的低代碼平臺開發工作就完畢了，明道云的應用系統不需要發布，配置后立即生效。所有用戶需要注冊明道云賬號來使用配置好的系統。配置完成的應用沒有獨立的應用程序，通過訪問明道云官網登陸后使用，移動版需要下載明道云APP，登陸后進行使用。
最后給大家展示下移動版應用的截圖，這些都是自動生成的默認設計，沒有做過調整。
通過以上例子，相信大家對低代碼平臺的能力已經有了一個直觀的感受。
軟件產品設計的標準結構是MVC模型，即Model（數據）、Controller（邏輯）、View（交互界面），低代碼平臺正是通過幾個核心組件，完成了對MVC三層架構模型的支撐，對應著MVC模型，這三個核心組件分別是數據模型設計器（對應Model）、流程設計器（對應Controller）、頁面設計器（包括了報表設計器，對應View）。
數據模型設計，實現了對底層數據對象的定義。我們之前已經提到過，不同低代碼平臺，對數據對象的定義實現方式并不相同。
數據模型設計器的第一種實現方式，是通過對象編輯器實現數據定義。這種方式靈活程度最高，將底層數據模型和前端視圖分離，模型聚焦底層，視圖是可視化的呈現。
國外的低代碼平臺Mendix，國內的華為云AppCube都采用了這種方式。另外大型商用軟件的低代碼平臺也都采用同樣的設計，例如SalesForce、紛享銷客等。
下圖是Mendix的對象編輯器，在Mendix中叫做Domain Model（領域模型），實際上領域模型和對象編輯都是屬于面向對象編程的概念。嚴格來講領域模型和我們之前提到的ER模型并不完全相同，領域模型擁有面向對象編程的特征，例如泛化、聚合，這些概念ER模型中是沒有的。
另外圖中展現的是Mendix的Windows客戶端版本，除了Web版，Mendix還提供了功能更加強大的Windows客戶端。經過簡單體驗，這套客戶端更像是開發集成編輯器IDE（程序員寫代碼的軟件平臺）。Mendix本身的功能也非常強大，當然學起來也更困難。
國外另一個知名aPaaS產品outsystems也采用了底層對象驅動的設計，并且也提供了windows版本的客戶端，安裝后有一個step by step的tutorial，非常驚艷！整套IDE風格的產品化設計，也非常強悍，讓人印象深刻！
華為云的AppCube貌似也是對象編輯器的設計方式，但因為我的試用申請一直未通過，所以只是通過幫助文檔做了猜測，無法具體體驗，如下圖：
數據模型設計的第二種實現方式，是表單引擎。
對于設計人員來講，只需要把底層的數據對象，理解成Excel的多張獨立的表，每個表通過表單采集數據。用戶定義數據模型，只需要將表單中的數據采集控件定義即可。
例如下圖，是釘釘的宜搭的表單編輯器，設計思路和明道云的表單編輯器類似。表單編輯器將數據底層設計和可視化呈現打包在一起，對于非技術人員更容易理解，但也會喪失前后端分離的靈活性。
定義了底層數據后，下一步要定義工作流。對于業務型軟件產品，工作流是支撐業務運作的核心。業務運行的本質，就是一個個工作流的執行。
淺層次的工作流，是類似于Workflow這樣的審批流，是對單一數據對象的處理；深層次的工作流，需要能夠支持多數據實體在流程中的自動化處理。后者是低代碼產品的核心功能之一，如果不具備后者的能力，基本上除了問卷表，什么系統都搭不出來。
什么叫多數據實體在流程中的自動化處理呢？
比如說銷售型CRM系統，當線索的狀態變為已核實，就需要自動生成一條待跟進的商機記錄，并將商機分配給合適的銷售，同時還要生成對應的聯系人記錄和客戶記錄，商機、聯系人、客戶的部分字段數據來自于線索實體。
這個業務邏輯規則，就需要復雜的工作流編輯器實現，在這條自動化處理流程中，涉及到了四個實體數據的增刪改查（線索、商機、客戶、聯系人）。
下圖展示的是Mendix的Windows客戶端版本下的流程編輯器。
下圖展示的是國內產品釘釘宜搭的工作流編輯器，感覺似乎過于簡單，只是一個審批流編輯器，也可能是我沒找到完整功能的配置界面？
對于業務型軟件產品，主要功能是對數據的增刪改查，而涉及到的交互頁面，多數也都是底層數據對象對應的列表頁、詳情頁，除此以外，還包括報表、儀表盤，以及其他類型頁面。
對頁面設計器的設計理念，明顯體現出了不同低代碼平臺的產品思路，整體來看，可以總結為兩類形態。
1）純粹的前端頁面編輯器
包括了報表、列表、視圖、表單，都在這一體化的頁面編輯器中實現。比如Outsystems的頁面編輯器，如下圖：
可以看到，這是一套復雜的前端交互組件設計器，包括了類似于數據表集合Table Records的集成控件，也包括了表單控件Form，以及其他各類型控件集合，例如復選框Check Box，單選框Radio Button等等。
在這套編輯器中，操作者可以定義例如列表頁、詳情頁、報表、儀表盤各類型前端頁面。再比如Mendix的頁面編輯器，也是同樣的設計思路，如下圖：
即便是dashboard，也是在同樣的頁面編輯器實現，如下圖是Mendix的dashbaord的demo：
低代碼平臺的報表設計器組件，和傳統的報表引擎沒有太大區別，都是基于底層的數據，實現前端可視化輸出，包括表格輸出和圖形輸出。以上是第一種前端交互設計的產品形態，可以看出，功能強大、靈活，學習成本也比較高。
2）大大簡化了的頁面配置器
將不同類型的頁面，進行模板化配置，主要分為以下幾類。
當然，低代碼產品也會提供集成頁面的配置，但功能要比前邊提到的功能弱很多。前文已經大量描述了明道云的視圖編輯器，不再贅述。
下圖是宜搭的頁面編輯器，展示了對某個系統首頁的編輯。相對明道云，宜搭的頁面編輯器更復雜一些，功能也更強大一些。
再例如，下圖是宜搭的報表編輯器：
數據模型設計器、流程設計器和頁面設計器，是低代碼平臺的核心，如果你理解軟件設計的MVC分層架構，就很容易理解低代碼平臺的核心產品功能，以及不同的產品思路。當然不同低代碼平臺還有更多各具特色的強悍功能，有興趣的讀者可以進一步研究。
可以看出，不同的低代碼平臺，設計思路并不相同。
產品的易用性和產品的靈活性之間存在平衡和取舍。例如，對于數據底層，究竟選擇表單驅動的設計，還是領域驅動的設計？這兩者區別非常大，后者對于非技術人員，基本不可用，而前者雖然易于學習理解，但功能確實也要弱化很多。
因此，低代碼平臺要明確目標用戶群體，究竟是給ISV或IT團隊使用的專業開發輔助工具，還是給非技術人員使用的強化版提效工具？前者更像是IDE的超級插件包，后者更像是Excel + VBA的超強易用版。
對于B端產品經理來講，體驗下類似于明道云這樣的低代碼產品，對理解軟件設計很有益處，不論是表單，還是流程，還是權限管理，所有核心的產品設計問題都會涉及到，并且能夠加深理解。
另外，萬一業務有個大型需求，研發沒排期，你3個小時就用aPaaS配置出來了，年度CEO特別獎不給你給誰呢！
楊堃，公眾號：PM楊堃（ID：pmYangKun）。人人都是產品經理專欄作家，《決勝B端》作者，12年互聯網研發、產品設計經驗，曾任VIPKID產品總監，百度高級產品經理，現為慢酷咨詢創始人兼CEO。
本文原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
