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

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

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

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

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

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

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