以Object 为中心和以Database为中心进行应用程序设计导致的后期修改的分析

      现在回想起来，当时触发了下面的这一段的思考的主要原因是当时在学习NHiberante的时候，对于基于NHibernate应用程序的设计方式的区别，是直接设计数据库然后设计对象模型还是先设计对象模型然后由对象模型生成数据库，当时主要是考虑到后期修改的影响。

       进行分析的依据是从数据处理的过程来考虑的，主要是获取数据、处理数据、展现数据的过程，针对如果Schema修改的话，将会影响数据库处理的各个方面的那些内容。





Database Schema修改影响分析:

1. 获取数据的过程。 如果获取数据的时候没有采用*，而是采用了具体的字段名，那么修改Schema必然导致对获取数据的表映射或者SQL或者视图或者存储过程等产生影响。而采用*的坏处就是存在效率问题，这在SQL中是不推荐使用的。另外还有一点，即便采用了*，如果有些新增字段或者其他表中计算字段依赖与*中的某些字段，这些地方也可能受到影响。

2. 处理数据的过程。 这个过程包含两部分：第一部分是获取数据后对数据进行处理，第二部分是保存数据时对数据进行处理。实现的方式有可能是通过服务器端代码来实现，也有可能借助数据库的存储过程或函数来实现。

               a) 获取数据后对数据处理。比如将数据展现为用户希望的数据，求合计值， 翻译枚举值，根据业务逻辑处理数据（比如根据根据一堆的单据计算费用列表），这些过程中都存在着对某个明确字段的处理。这时候database schema 修改会对这一过程产生影响的。

               b) 保存数据的时候对数据处理。这个过程主要是对用户输入的数据进行校验和处理。比如有效性校验，唯一性校验，业务算法处理，生成冗余表等。这个过程基本上没有通过*来处理数据的吧。所以这个过程受到 database Schema的影响是最多的。

3. 展现数据的过程。 这个过程中使用*的是有并不多见，基本上都是明确的字段。主要是因为根据用户的要求，字段存在展现顺序，字段有独特的展现方式，有些对字段只读、编辑方式的规则等（以公司的GSF为例），像这些地方都是以具体的列名呈现的。数据库的Database Schema修改对这里影响最大。当然这些变化可以隔离到获取数据的过程中，如果这样的话，就不能在获取数据的过程中使用*，因为获取数据的过程存在的一个任务就是要对界面呈现的字段和数据库的字段进行映射。界面处理比较麻烦的还有一个地方就是同一份数据可能在多个地方展现，比如说弹出窗体，列表，报表。从工作量上来说修改Database Schema，界面修改的工作量最大了。此时最好的做法就是界面的设置要文本化，可以批量替换，然后冒烟即可。

综上所述：当database schema修改的时候，在一个以Database为中心的Application中，获取数据、处理数据、展现数据的过程都会受到影响。其中展现数据和处理数据的过程受到的影响最大。

如果是采用Object的方式的：

1.获取数据的过程：如果是根据ID获取某个对象，那么当Domain Class修改的话，编译即可发现问题，如果是HSQL或者criteria方式或者SQL，这个过程中由于这些属性都是通过字符串形式展现的，比如上面的HSQL查询例子中，那么像这些地方只有运行时才能发现错误，编译时发现不了错误，Domain Class修改的还是会产生影响。想想，这个问题或许可以通过单元测试来解决。

2.处理数据的过程。 这个过程由于都是通过Object来进行处理的，所以基本上不受到影响。当然要保证获取的数据时正确的。

3.展现数据的过程。这个过程不了解，暂时留个疑问。

           当然，上述假设的前提是可以根据Object Mapping Files来生成Database，在这种情况中，基本上不需要在Mapping Files中指定列名。如果指定了列名，那么可能修改的只有Mapping Files一处地方，比较集中。这也是比较好的事情。

综述：
        依稀记得谁说过在设计一个数据结构或者类的时候，最好要有self-dected的信息，不过像这种DataSet 和Database的关联关系就比较麻烦了。如果都采用*还可以，如果通过具体的列名来指定映射，一旦Database Schema修改了，那么其后的一切都是要修改的。从目前对NHibernate了解来看，Database Schema修改后同样需要修改Mapping Files，不过从另一个角度来说，如果所有的一切都是以Object为中心，那么当Object某个属性修改后，首先在Class的层面可以通过工具都修改完毕，编译通过应该就没有什么事情了，然后根据Mapping Files生成相应的数据库。这貌似也是NHibernate的一个优点。

        在一个应用程序中，数据库修改多是增删操作，而修改某个字段的名字的情况则比较少见。不过对于增删字段或者表的操作，如果能够在编译时就能发现或改正错误总比在运行时报出来好一些。运行时发现的错误多数都是地雷阵，有时候需要一个工兵集团军才能排除彻底。