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

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

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

只不過2004年我已經不太愿意到郵局去寄信，而是愿意用email發郵件,OFBIZ這樣的整合工具，用在小規模的系統里面還是很有優勢的。

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

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

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