Visual Studio功能可以实现修改测试代码和方法，还有相关Visual Studio功能的策略。然而，我们要改变折扣策略Visual Studio功能，就要重新编写一下代码，还有一些文件配置的相关问题。
设计数据模型的重点不是去分析到底什么地方是可变的，什么地方是不可变的，业务会以什么样的方式变化（OO里面经典的Hotspot分析），所以整个系统慢慢会变成一堆数据，根本无法理解它真正的行为。
其实我要求不高，给我一个对象的世界，让我实现业务，你去展现、去持久、去分布，不要让别的东西来打扰我。当然，万一我需要数据你也得给我，我还要做报表呢。呵呵。
看来你是比较倾向对象建模 呵呵，这样就引出对象建模与关系建模的争论了 我是比较喜欢关系建模的，很简单，我不会对象建模……（别拿板砖砸我） 关系建模的基础是集合理论，而集合的研究在数学上是比较完善的，可以说，关系建模是有一个严密的理论基础。Visual Studio功能这个基础是相当简单的－－至少概念是这样。
简单往往意味着高效。 而对象建模呢？我不清楚 基于集合理论的关系数据库在处理数据的性能上是无可匹敌的，对象数据库的效率绝不可能和关系数据库处在统一水平线上。完全的面向对象数据库搞了十几年了，始终无法打入主流市场，这是一个很主要的原因。
本不用讨论Visual Studio功能。基于对象的数据库倒有几个，但我的看法实际就是关系数据库的底层上加一个ORM，只是这个ORM做在数据库端。 到底什么是对象建模呢？各位老大能否给我等扫扫盲？#t#
然后我们就可以修改测试代码和方法实现，直到完全满足以上的折扣策略。然而，Visual Studio功能这意味着如果我们要改变折扣策略，就需要重新编译代码，至少也需要修改配置文件。
如果这段逻辑存储在一个数据表里，那么我们可以将订单的价格传入一个存储过程，然后在表中查询折扣数量。不过，当我们着手创建Visual Studio功能表格和存储过程时，很快就会遇到一些问题。这个表格的结构是怎么样的?我们该如何表示一个范围的最低值和最高值?如何处理边界情况?
