OOPAA

@jinfeng_wang
hi, 具體的解決方案其實倒不重要
這篇文章試圖展現一種開發方式：
通過分解功能需求，按照OO思想設計，使得每個階段的工作都能是原子性質的重構

@娃娃
好，希望有機會能跟你做進一步交流

@BeanSoft
多謝beanSoft支持

@Robin's Java World
多謝捧場哈

@pythonfly
看來老兄對python頗有研究啊
對python，我倒是不熟
希望以后能有機會請教python:)

1. play的JPAModel實現的機制是這樣的：
基類里面的靜態方法(User.save)默認實現拋出異常，只有在子類上生命@Entity之后，play框架自動幫你的子類實現字節碼增強。
其實，這個方案也是在java平臺的約束上實現class.save方法的無可奈何之舉，但這個過程是用戶不可控的，所以也是我比較反感的地方。

2. java是沒有可以動態給一個對象增加一個方法的功能，而且無論如何也沒有辦法獲得這個功能。
嗯，對的。因為java里面的class不具備ruby里面的概念，只能是修改字節碼修改默認實現。而這也是play的實現方式。

3. 習慣了有DAO，Service，習慣了返回的時候配置一個返回文件，所以你給他一個簡單的做法
嗯，沒錯。傳統的web mvc開發模式已經限定了很多開發人員的思路，laying/iop 這些好的開發模式被僵化成為教條。但是play如果致力于消除laying/iop，那就找錯靶子了：
1). 這些開發模式都只是形式，而不是本質，本質是后面的分離關注點、SRP或者DIP。
2). play開發一個簡單的domain，肯定是很順手的。但是面對復雜domain，以及團隊里面的開發，這時候靜態方法、修改字節碼就成了它的軟肋了。

所以，面對程序開發被教條化的時候，我們更多的是要考慮通過回歸OO,使用OOA/OOD來重新評估項目框架的優劣。如何保證既提供一定的限制和約定，又提供充足的自由讓開發人員揮灑設計？
我覺得play并沒有很好的做到這一點。

@hcom
這個倒沒有研究
因為我只是想研究里面一些比較新穎的東西和想法

如果你能花些時間做這方面測試
那對于我們就再好不過了:)

@hcom
這個就是見仁見智了，也沒有唯一答案
作為堅持OO 和 Testable的“狂熱分子”:)
我是不能接受的

@7047
django我倒是不熟,只是 play!宣稱rails-like,所以也是這樣理解的

能詳細比較一下django和play么?

@太陽里的雪
現階段的play! 的確只能算是個玩具
一些編程理念和普遍接受的理念大相徑庭

稍后我還會推出其他的博文來分析play!種種之痛的
敬請期待:)

@太陽里的雪
是的，這是play! 要求的convention
被寫死在Play類里面了

@太陽里的雪
你說文件目錄結構怎么搞是什么意思？
是說怎么放置相應的文件么？

你可以看看/resources目錄下的application-skel文件夾
這下面就是新建application的skeleton

@路過
沒有萬能的銀彈
可惜很多時候人們會被冗繁的日常工作蒙蔽了決心和判斷
這時候，敏捷教練或者工具就可以起一個mentor的作用了
當然，敏捷教練是深入到開發過程中去，了解具體的pain point再對癥下藥
所以有位同事風趣地將其形容為“挽起袖子做咨詢”:)

見appurple回復
document中有專門說明

@一臉大鼻涕
springmvc 的確很不錯
其實看rod johnson的 without ejb,就知道他對web開發的理解多深刻
但畢竟不是專門做這塊的, springmvc還是存在幾個硬傷, 以后詳加解釋

@paul xu
對, 消費者以及服務者提供了類似的定義
其實這也是提供了一種構建系統的方法

Integer,Float,Double都有parseXXX方法
自然Character也不應該少這樣的方法

至于實現原因, api已經說的很明白了

不錯
其實工作流引擎最難的是流轉的定義和抽象
1. 如何將復雜的業務流程抽象成線性, 分支或合并的圖形學關系
2. 如何提供dsl或腳本語言讓業務專家編寫工作流規則

更友好的是將input和select位置重疊
直接輸入選項內容,回車即添加

SOA戰略已經極大了提高了IT架構的抽象程度
原來的高層中間件之類，也變成了服務的基礎設施

真是令人激動和期待

應該是個很不錯的公司
希望以后有機會合作
關注

Benq還是一個很值得尊重的人
只可惜出現的時機太早了

所謂和久必分，分久必合

Android 也不是能長期一統江山的

當然，這對于敵人的敵人是再好不過的消息了，那個作壁上觀的微軟，那時可能已經笑得快合不籠嘴了。

哎，google何必呢

很值得期待
最好是在eclipse中有更好的支持

跟jdw同感
不可避免的有點傾向

個人認為easyjweb確實提供了很多便捷的方法
不過，在ror,grails這些敏捷框架的沖擊下
easyjweb有多少值得稱道的地方還很難說

明顯是托
說struts2”掛羊頭賣狗肉”，背后的webwork是狗肉？
webwork是狗肉，easyjweb那得是什么肉？

宣傳也找個好點的理由撒

果然不錯
要是能提供撤銷拖動的效果就更好了

嗯
領教了
地址由最初到現在，在空間和時間上都發生了很大的變化
最顯著的特點就是更耦合了

我這個理解沒錯吧？

設計的精髓在于當某種變化來臨時，能夠重新審視，甚至是調整全部的設計，讓它能夠兼容之后的“同種類”變化，從而使今后再有這樣的變化時，帶來最少量改動。為此目的，哪怕是推翻重來也在所不惜。


比較含糊
“推翻重來也在所不惜”，這是不是說好的設計允許推翻重來？

而且，這些要求需要極其豐富的設計經驗才行
經驗足的，全面的設計是很自然的事情
經驗不足的，自然還是需要思考越全面越好

印證到當前的視頻網站
普通用戶來承擔內容提供商
網站充當應用提供商和業務支撐系統運營商的角色,而一方面又是半個內容提供商

是否?

一直關注呢
再做個eclipse上的吧，呵呵

1. 內嵌數據庫Derby
2. 自動加載數據庫驅動
3. SQLXML
4. SQLException增強
謝謝lz

這樣的框架并不難實現
但是要做成通用框架，你就知道配置抽出框架的好處了

@javazhai
同意
嗯，我以前也看過這樣的文章
字體占了太多的資源

時間勉強夠用
~~~~~~~

scjp應該很簡單啊

收到lz的郵件
謝謝

lz發一份給我研究可以嗎
skyairmj@gmail.com

很難講現在的選擇從長期來看是不是最優的
只能保證短期內是極大值吧

能不能做個獨立運行的版本出來？

已收到
謝謝

感覺就是代碼糖而已

不過，還是支持你們

一個技術負責人帶一幫剛畢業的大學生,經過一到兩周的培訓,就可以 進行正常開發,所有的技術學習曲線很低,每個人可能不太明白具體細節或者原理怎么回事,但是首先能用起來,而不是發愣.



....貌似lz的這個原則spring可以滿足了

skyairmj@gmail.com
謝了先

...框架的侵入性也太強了一點

1、is null和字段=null
這種在oracle和sql server中非常明顯，前者為oracle的，后者為sql server的。


sql server 是 is null