Annotation到底是“银弹”还是灾难?
随着软件越做越大、越做越复杂,配置文件也多如牛毛,于是我们开始在代码中写入Xdoclet Tag或Annotation代码,使用自动化工具生成相应的配置文件或者规避配置文件。
我开始想,配置文件的作用是什么?难道不是对软件进行解耦吗,比如在持久层和数据库之间解耦,以便更改数据库地址、用户、密码、表名之后不必再build代码。一个大型的开发团队可能有编码人员、架构师、测试员、部署员、数据库架构师这些角色,而且这些角色可能不由一个人担任。这些人之间的沟通也许不会通畅,客户与开发团队间也会存在沟通不通畅的时候,于是特别经常必需在客户的生产场所直接build软件,因为这时总会有代码与客户现存的生产软件之间有不匹配的地方,为便于修改于是直接选择在客户生产场所build。但是在软件交付运行之后,客户可能存在特殊的商业策略,比如定期更换数据库连接帐户的密码,这就不可能采用将密码硬编码在软件中的方法,因为每更换一次密码就要build一次软件这是不可思议的。如果采用配置文件就能解决这些问题。
问题是,既然配置文件是将易变的代码从硬编码的困境中解放出来,那么Annotation不是将一切回归原点吗?修改硬编码的配置再build软件和修改Annotation再build软件难道有区别吗?使用配置文件就是为了随时随地、容易的更改,而Annotation无疑让这些更困难了。
如果客户采用的策略是直接修改配置文件,那么他又不得不同步源代码中的Xdoclet Tag;如果采用Xdoclet Tag方式,那么他又不能较方便的更改配置文件;如果采用Annotation方式,那么他又不得不重复build软件。
我并不否认Xdoclet Tag的用处,在初次生成配置文件时它确实可以减少书写工作量,但是只要生成了配置文件之后,就要在同步Tag和配置文件上下功夫,这个工作量是以前所没有的。但是我实在搞不懂,回归紧耦合的Annotation到底好在哪里?Hibernate、Spring等框架一直致力于使用外置的xml文件来实现解耦,而Annotation一夜之间就让这些轰然倒塌。这些框架一开始费那个劲干嘛,直接做成硬编码不就好了。
因此,我在想对于开发团队来说,采用Xdoclet Tag生成配置文件的方式更好;对于客户来说,直接修改配置文件更好;对于Annotation来说,它本不该存在。