因此，我们需要添加一个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 框架已经是非常多了。
