用戶界面模型

這個有比較好的解決方案嗎？或者僅僅在草紙上劃兩下子？

@讀書、思考、生活

偶爾轉回來，看到點名回復了……

那會兒給出那個RSS的鏈接，不是為了指出網站自身，而是數據來源：一大堆的Java“山頭”？

殊途同歸吧

樓上所言KEWELL的文章不知道是哪個，沒看過；
對我而言，則一搞不明白模型驅動是什么，事實上按照我的觀點，所以的人類活動都是“模型驅動”的－－稍后也寫個隨筆表明這個觀點

讓我非常困惑的就是所謂模型驅動到底對于實際的工程能有多大的幫助？如果沒有模型驅動的工具支持，根本談不上模型驅動開發

讓我汗顏的是：這樣的描述，并不能增加我對模型驅動的直觀理解……

我的方式是保證準確性，在這個前提下，用多幾個“包”來分解，這樣也基本上可以做到“清晰”。這個包，當然不是將來要設計實現的東西，僅起到輔助表達的作用。

我覺得可以參考Gmail的標簽方式，對于模型中任意元素都可以打上任意的標簽，這些標簽的真實含義可能對應層次、視角這樣當我們想要從某種視角或某個層次來看問題的時候，只要把標簽相關的元素抽取出來即可

這個需要建模工具的支持

第一次覺得枯燥，第二次看還是枯燥

枯燥之余又覺得精辟，里面用了物理和邏輯的一些術語把人帶入了另外的思維方式

閱

2.5維的說法很有意思

漢字有象形之說，只是不太意識到了

最近再次鑿摸關于模型與建模，又有所得：其實jerry兄所言兩種“數據驅動”和“模型驅動”都是宏觀意義上模型驅動開發的特例，二者分別對應的模型不同，數據模型－－領域對象模型？

POJO和盡量多的分層，一個類只負責一個功能，這樣子，管它什么框架什么技術都可以很容易的加個新的包裝

世界是由分子構成的，我覺得這也是XP的核心思想。任何復雜的事情（物質）都是由最簡單的事情構成的，都可以分解為簡單的事情

留個記號先
慢慢看來

@errorter
我們還有C/S應用的部分，也用Ruby，未知的陷阱太多了

@idior
把評價因素改了，長遠的技術選擇要兼顧，更重要的眼前，呵呵
對于我們的項目而言，有兩個因素：
1.找到一個半成品（開源框架），解決企業應用中的一些共性問題，加快進度
2.解決B/S與C/S下的圖形繪制問題，目前Java和Dotnet下都在做這方面的工作。且圖形的交互能力，比如拖動圖片上的元素，暫不考慮

當然到最后發現，真正決定因素：
1.領導/開發團隊喜歡什么
2.開發團隊熟悉什么
3.哪種技術能讓開發團隊先熟悉起來

我說電驢和BT的時候，其實就是指的整個的系統而不是BT客戶端。BT也算是一種網絡傳輸協議了吧？

Bitcomet的DHT網絡的引入應該降低了對數據中心的依賴；最新的exeem，則干脆不需要數據中心了，只是因此速度很慢，所以不再用了。

這是能夠接觸到分布式系統。商業環境中沒用過：（

首先感謝canonical對我在上個Blog中提出的問題進行了解說

這次兩段的文字雖然不長，又讓我考慮了老半天，感覺仍有推敲之處：
架構的無侵入性，指的是架構對于外部接入對象沒有特殊的形式要求，這種無侵入性在事實上“降低”了外部對象與框架本身的依賴關系－－是“降低”，而不是沒有了。所以從這個角度講，所謂“無侵入性”是根本就不存在的，只能降低“侵入性”，即術語應該是：“低侵入性”。剛剛搜到一篇文檔也是說這個問題：
http://www.dingl.com/view.shtml?xh=474

再來看可退化性和低侵入性的關系：
低侵入性，指出了框架在進行擴展時的復雜度降低，對框架的依賴降低，通常就是我們希望的靈活的擴展能力
可退化性，則描述了，可以把增加的這些擴展，很方便的unload
這樣，低侵入性造就了可退化性。

關于Blog中舉出的RPC層，這個很讓我困惑：因為它看上去，真的是“無侵入性”的。不過后來想想，這個RPC層實際上還是有所依賴的：它必須處理request和response？

@非魚

IE、FF不是：按照分布式系統“每個節點都有自己的應用服務器和數據庫系統”，它們沒有提供服務的功能

eMule和BT則不同，每個節點都有自己的應用服務器和數據庫系統（雖然簡單了點，確實提供了服務；數據庫系統可以認為他們使用的是文件型數據庫）；

分布式系統未嘗不可以采用emule和bt協議來進行信息的訪問和復制吧？分布式系統是P2P的一種，或者P2P也是一種分布式系統？

Sybase Replication Server能夠復制的信息對象有哪些？

象電驢、BT這種算是大型分布式系統嗎？

能否試舉一例？比如銀聯，這個是否算是大型分布式了？

@非魚

好半天才鑿摸過勁兒來，"robber's boat"，強盜的船，原來就是俗語的“上了賊船”啊，貼切

英語也有這種說法？

◎非魚

Enterprise Level的界定就是你上次描述的四條？
『
1. Is it a information collecting/organizing/OLAP system?
2. Are you preparing to use Workflow in the coming system?
3. Do you have any complex business process?
4. Is it a real distributed system?
』
或者說Java比之Dotnet在Enterpise Level方面到底強在哪里？

今天化了一天的時間開評論會；邀請了其中一人是以前的同事，現在在微軟中國。他有著對微軟的強烈認同感、榮譽感，對dotnet的技術體系也非常熟，一整套分析方法分析下來，大家填寫評估表的時候基本都選擇了Dotnet...

到場的Java開發者，缺少架構師級的能力，所以被比下去了；另外讓我感到困惑的是：似乎使用Java同時做B/S版和C/S程序的公司并不太多？大多使用Java更多聚焦在Web模式的開發上，做Web開發使用的技術又不盡相同，即使選擇了Java，還得在一堆Web框架里進行選擇...

請大家繼續大力支持?。赐炅?，給出寶貴意見啊～～）

公司在北京，有能力有時間的朋友想提供技術支持的話，歡迎與我聯系 ！

@Fantasysoft

“各種各樣的技術都有它所適合的應用場景”，說得好！
本文雖然也描述了一個業務場景，只是之后的評估并沒有直接針對這個場景的關鍵決定因素來展開－－僅僅是對幾個因素的宏觀對比，這幾個對比的結果，僅僅讓我親Java而遠Dotnet。

天下熙熙攘攘，皆為利來利往

上述問題可以認為是過高的使用了利益杠桿來調節企業的行為

想要達成的其實是可持續發展這樣一個目標

呵呵，當成論壇來發東西了吧

榜樣啊，學習！

“最大的不足在于自己缺乏一套系統的、理論的系統設計過程的指導”

項目實施完畢，覺得萬事OK；每每碰到新項目的時候，就打怵，下不去手

期待分享更多心得

@非魚

Sorry,是我誤導了你，修改了Blog中關于業務場景描述的部分。

其中核心問題：作為一家行業軟件提供商，要形成自己的企業應用框架[6]，并在該企業應用框架上搭建行業的整體解決方案。也就是把各個系統中共性的、普遍性的問題提取出來，形成“企業應用框架”。其它的業務功能，用同一開發平臺重新實現為業務功能模塊。最后通過企業應用框架和業務功能模塊，組裝成產品系列。

關于你上面提到的幾個問題，由于現在我們服務的主要客戶是中小企業，所以關于工作流等，考慮使用免費的方案；數據挖掘，以前沒用，近期也沒有打算...

@非魚

我想是“解決企業信息化中的信息孤島，形成統一的整體解決方案”這句話，使你認為我應該focus on Enterprise Application Integration than technology choice

實際上，我這句話并不是通常所言“信息集成”，和EAI關系也不大。我說的信息孤島，是指我們現在幾個產品之間，互相獨立，各自有自己的組織機構和權限管理，開發語言又各不相同，這帶來的問題是：我們需要用不同的開發工具（開發語言）維護多套產品中的組織機構和權限管理，多次重復勞動；且代碼模塊不能很方便的被新的系統所重用。

現在要做的工作是，把PB寫的產品A使用Java(或C#)重寫,把用Delphi寫的產品B也使用Java重寫，把VC寫的產品C同樣也使用Java重寫，同時把各個產品共用的模塊，比如組織機構、權限管理等，只要維護一份代碼就OK了。為企業實現定制功能的時候，由于全部功能模塊都是由同一語言實現的，所以可以靈活組裝成滿足企業多個要求的“整體解決方案”。

Do I make sense?

WideWeide,申請加入

因為在設計中遇到無數困惑，以砸磚為主...

每次看到樓主的文章，都有嘆為觀止的驚艷感覺，原來問題可以這么思考的，忍不住要上下其手的摸索一番...

------------------
架構的可退化性---這個是說架構的無侵入性嗎？

-------------------
架構師不是預言家. 在多變的業務環境中, 架構師的目標不應該是預測到所有的變化可能, 并把它們表達到系統架構中. 這個世界上不乏一些耗資數十億,設計三四年,但最終每個談到它的人都要說一句shit的產品開發項目. 架構設計所能做到的最好的程度是自然的標注出系統的結構邊界,成功的delay各種技術抉擇.

這話真是太經典了，到了最后發現，所有項目的相關人員的利益擺不平，都成不了事兒

剛起了頭呀，繼續關注

業務代碼重用的前提是它經過業務專家的提煉、業務過程完整、可完全配置

這是一個長時間積累的過程，往往是不等到形成就game over了

關注...
正好要做圖表的東西

1. 版本主次不分

通常我們描述為標準版本、定制版本。標準版本是符合大多數企業的通用版－－標準版。為具體企業定制的版本，不是所有功能都適合放到標準版中，這樣定制的版本多了的時候，管理起來也很麻煩。定制的多個分支交叉開發的時候，有些是共性的能夠合并且應該合并到主分支，有些則不然

“不就是改幾個頁面嘛”

這個我看是需求的改進速度和技術水平的實現能力之間的差距造成的；從需求來看，就是改幾個頁面，結果跑到后臺怎么就那么多工作要做，要是跟其它模塊還有耦合，就更要命了。良好的架構和設計，能夠預見可能的變化和調整，并在架構上給以支持；自動化的測試、打包、發布機制等會有所幫助吧？探索中…

GBean和osgi比較呢？

幾個月前就讀過，再次讀還是大受啟發。

尤其最后“帶來的思考”更是我現在感到困惑的。JBoss會考慮把JMX換成osgi？

何為DJ？

繼續關注。
樓主不會是學物理的