对配置性编程的一点看法

人有追求高灵活性的倾向，这种心理源于对需求变化的恐惧，而在这种心理（一部分其实是从众心理）下，要对事务保持一定的“中庸”是很难的，例如，现在的编程就形成了这种过度配置的局面。似乎不采用配置性编程就不是编程一样，下面看几个例子：
1）Hibernate，EF等框架的实体及关系映射
本来数据库里已经定义了一套完整的规则（包括表结构和表间关系及约束），早期的这些框架还非得把这种规则在配置文件里重新实现一遍，好处肯定是有，因为任何事物都有两面性，但如果系统稍微复杂一点，这种做法实际上是坏处远远大于好处：
A）要维护两套规则的一致性，不要小看这件事情，如果没有强有力的管理工具，这都是噩梦；
B）你无法定义所有的实体关系映射，举个简单的例子，对于企业级应用，用户这个表几乎和其它所有表都有外键关系，而且一个表中还有多处这种关系，如果你的访问依赖这种关系映射，你如何映射呢？
C）你无法应对一个字段的多重映射，比如，一个字段A是外键字段，但这个A可以同时来自于N个外键表，你如何应对？不要告诉我产生这种映射是设计有问题，在企业级应用中这种处理方式其实非常普遍的处理方式。因为可以保持业务逻辑的一致性，从而可以大大减低业务复杂度，开发工作量以及增加灵活性。很多时候这种设计是为了在业务层级上应对需求变化。

2）程序关系的IOC和AOP
适当的采用注入和依赖倒转这种方式是没有任何问题的，解耦一些硬连接确实可以增加灵活性，但同样需要度。IOC和AOP的这种解耦方式实际上是不利于理解的，因为这违背了人的直觉认知方式。根据我在实践过程中的经验，只要设计相对合理，80%以上的调用关系（连接）一旦确定，在整个系统生命周期中都不会被改动。而且可能变化的20%中变动频繁的其实也非常少，真正变动频繁的我们往往都参数化了，而且这种参数化都直接放在数据中，也不会采用注入类的方式进行。
在讲AOP时，很多书都会把权限和日志功能的注入放进去，其实这完全是一种误导，因为这两种功能在应用中具有特殊性，具有可预计的规则，并与其它业务逻辑关系不大。而这些功能在设计的时候都会考虑进去，完全不用采用注入的方式来进行。而真正普遍业务性约束在企业级应用中很少，你切面只会把事情弄得很复杂。无论是调试，理解和维护都非常困难，会导致软件的开发和维护成本过高。

十几年的经验告诉我，最好的复用在业务模型上，最好的灵活性也在业务模型设计上。如果在业务需求的分析中，你无法抽象出一定的业务模型，无论你在编程中采用什么技术，其实你都很难应对需求的变化。

后记：这篇后面写得有点过了，还是万事皆有度好。