因此，我們需要添加一個Visual Studio數(shù)據(jù)來比較我們的期望值和返回值。在我們的Visual Studio數(shù)據(jù)部分中，刪除Visual Studio數(shù)據(jù)，然后在下拉列表中選擇Scalar Value并點擊添加按鈕。

OO程序的效率不一定比數(shù)據(jù)+過程的速度慢，原因是OO更能實現(xiàn)Once and Only Once，更容易分析問題的瓶頸，也就更能優(yōu)化效率。效率的優(yōu)化不是在100%的地方優(yōu)化，而是在20%的地方優(yōu)化。

--舉個實際的例子，OR Mapping一般比你手寫的程序效率高，因為在一個ORM產(chǎn)品的發(fā)展過程中，它只需要在幾個有限的地方，針對某幾個有限的影響效率的地方進(jìn)行優(yōu)化，而一般手工編程需要在很多地方進(jìn)行優(yōu)化，并且沒做一次都要去手工編寫，手工維護(hù)，手工優(yōu)化。OR mapping則吸收整個社團(tuán)的專家知識，不斷地重用和進(jìn)步。
 
退一步來講，就算你是一個非常高的數(shù)據(jù)庫編程高手，你寫出的代碼比O/R的效率高，你不能保證每個地方都可以這樣，你也不能保證每個人都這樣。而軟件項目是團(tuán)隊工作。
 
OO的重要作用是程序的可擴(kuò)展性、穩(wěn)定性和適應(yīng)變化，以及使用面向用戶的語言和概念分析問題和解決問題。這是比你在數(shù)據(jù)庫存儲提高5%（如果有的話）更重要的效率和優(yōu)化。
 
2004年還在談?wù)摂?shù)據(jù)建模和對象建模的優(yōu)劣，我想對大多數(shù)程序來說是非?？尚Φ?。這應(yīng)該是1994年談?wù)摰膯栴}。但我不是說數(shù)據(jù)建模就沒用了，數(shù)據(jù)建模照樣可以解決問題?，F(xiàn)在很多人還在用C和PB寫管理系統(tǒng)，他們照樣能夠做得出好程序來。是否能夠很好地實現(xiàn)用戶的業(yè)務(wù)是最終的。

只不過2004年我已經(jīng)不太愿意到郵局去寄信，而是愿意用email發(fā)郵件,OFBIZ這樣的整合工具，用在小規(guī)模的系統(tǒng)里面還是很有優(yōu)勢的。

我對 Ofbiz 的體會也不是很深。Ofbiz 把原先必須通過 Java 編程解決的問題轉(zhuǎn)化為用 xml 文件進(jìn)行數(shù)據(jù)建模，確實很大地減小了開發(fā)工作量。很多原先必須編程解決的問題現(xiàn)在只需要寫 xml 文件就可以了（更多的 xml 文件，更少的代碼量）。 #t#

我們做的是 MIS 類的數(shù)據(jù)庫操作密集型的軟件開發(fā)，所以我們的框架也是以數(shù)據(jù)建模為核心的。對于業(yè)務(wù)框架的可重用性，我的考慮是這個業(yè)務(wù)框架是為了解決更復(fù)雜的業(yè)務(wù)問題，即為了更大范圍的重用而設(shè)計的，其中每一部分的可重用性并不是非常重要，各部分耦合緊密也無可非議。

這是由它的設(shè)計目標(biāo)決定的，因為每一部分不是設(shè)計來單獨使用，而是為了一個更大的設(shè)計目標(biāo)服務(wù)的。如果你只喜歡其中某一部分而對其它部分都不喜歡，那么***完全不要用這個框架，而使用更適用的輕量級框架。好在現(xiàn)在可用的 Java 框架已經(jīng)是非常多了。