? 嚴(yán)格遵循 CQRS 原則，更新 Model 的函數(shù)和刷新視圖的函數(shù)應(yīng)該是兩個函數(shù)，分別是對用戶輸入事件的響應(yīng)和Model改變事件的響應(yīng)。這樣刷新視圖不會再引入新的事件，減少循環(huán)的幾率。
? 使用細(xì)粒度的事件。粒度過粗會引發(fā)不必要的響應(yīng)，增加循環(huán)的可能。
致遠(yuǎn)服軟認(rèn)為：http://www.soft8.com.cn/談到事件的粒度，過細(xì)的粒度會引起另外一個問題：注冊事件處理函數(shù)太繁瑣，不易看清交互。Event Aggregator可以來解決這個問題。
模式：
最后我們回過頭來看一下已有的幾個大連工業(yè)大數(shù)據(jù)二次開發(fā)模式各自的重點(diǎn)。
? MVP 比MVC 更強(qiáng)調(diào)大連OA系統(tǒng)二次開發(fā)顯示邏輯跟視圖的分離。
? MVP，Presentation Model和Passive View都強(qiáng)調(diào)視圖跟顯示邏輯的分離，程度不同：MVP引入這一分離，Passive View分離的最徹底最可測，Presentation Model介于兩者之間。
? Presentation Model比MVP和Passive View更強(qiáng)調(diào)的是為顯示邏輯創(chuàng)建單獨(dú)的Model，而不是依賴于Domain Model。
更全面的比較，請參見老馬的《GUI Architectures》及里面的鏈接。
自動化腳本之于軟件開發(fā)，猶如地基之于建筑。
在大連工業(yè)大數(shù)據(jù)二次開發(fā)過程中，缺乏一個好的自動化腳本，與之相伴的往往是日常的開發(fā)工作舉步維艱。
? 只有少數(shù)人能夠把整個軟件構(gòu)建起來，因為構(gòu)建所需的那些東西不太容易弄全。
? 為了能在自己機(jī)器上寫代碼，開發(fā)人員要花大量時間在IDE 上把工程配出來。
? 提交代碼之前，開發(fā)人員總是忘了再驗證。
在本文中，我們將以一個Java的Web項目為例，展示一個好的“地基”應(yīng)具備的一些基本素質(zhì)。在這里，用作自動化的工具是Buildr。
Buildr是一種構(gòu)建工具，它專為基于大連工業(yè)大數(shù)據(jù)二次開發(fā)的應(yīng)用而設(shè)計，也包括了對Scala、Groovy等JVM語言的支持。相比于Ant和Maven這些Java世界的“老人”，Buildr算是小字輩，也正是因為年輕，它有著“老人”們不具備的優(yōu)勢。
? 相比于Ant，遵循著Convention over Configuration 原則的Buildr 讓“編譯、測試、打包”之類簡單的事做起來很容易。
? 相比于Maven，我們無需理解強(qiáng)大且復(fù)雜的模型，而采用Ruby/Rake 作為腳本的基礎(chǔ)，也讓我們可以定制屬于自己的腳本。
簡而言之，它滿足了我們選擇工具的基本原則：“易者易為，難者可為”。
請注意：下面所有的內(nèi)容并不只是Buildr的獨(dú)家專利，而是每個構(gòu)建工程都應(yīng)該具備的，差異只在于，選擇不同的工具，實(shí)現(xiàn)的難度略有差異而已。
易者易為
讓我們從一個簡單的buildfile——Buildr的腳本——起步。
