它是Rails技术的核心原则，逐渐也成为了敏捷开发技术的一个重要思想。最早看到它是在一个朋友的MSN上将它作为个性化信息，想对它有更深入的了解是在自己越来越多的开发实践中遇到的各种各样的配置麻烦时，希望与它交成好朋友是在总结这些开发实践后。
约定胜于配置不仅是属于Rails，属于开源技术，它同时间属于.NET技术的开发人员。我以前就有这样的一个误区，配置文件越多，能配置的东西越多，软件的适应性就更强了，修改更简单了。为此，在以前的，包括现在的项目中都会有很多的配置文件。后为慢慢的发现，有了这些配置文件后，事情并不是你想象的那样简单。配置文件就像一个沉重的包袱，极大了阻碍了你前进的步伐。一个发布时可运行的程序，部署到不同环境中，却不能正常运行，经过痛苦的DEBUG后，你却发现，是由于你的一个配置值所引起的；你的软件是前几年开发的，但是现在出现问题了，你要重新部署，但是你又会发现，你不知该如何配置它，可能得放下手上的工作，重新去研究这些配置文件；在开发时，我们预留的一些配置值，有很多你会发现，其实这都是我们的一厢情愿；这时候我们该怎么办呢？
前段时间在http://weblogs.asp.net上，也有人发表了一篇blog叫.NET Configuration Hell。作者跟我一样，也有因为配置文件带来的烦恼，它提出的最糟糕的做法是为每一种不同的环境维护不同的配置文件，最理想的办法就像Enterprise Library一样，提供集成的配置工具，难道有了配置工具就能完全解决这些烦恼了吗？
可以说我是Enterprise Library的第一批推崇者了，但是它那烦多的配置文件可是让我有深刻的印象，也让我后面在维护那些程序的程序时带来了不小的压力。虽然去年我还在用，虽然它已经推出3.0版本增加了很多功能，虽然它的配置工具的功能更强大了，但是我现在已经不用了，不到万不得已，也许以后再也不会将它使用在项目中了。但是，做为一个MS唯数不多的开放源码的官方项目，它优秀的架构是值得所以.NET开发人员去深入学习的，但是将使用到项目中，一定要深思，因为它有太多的配置文件了，因为它目标群体太大了。
我还想说说前段时间一直在使用的iBatis.NET。它很优秀，也给我带来了很多的方便。但是使用了一段时间以后，却发现它的配置文件太让人伤脑筋了。也许在DEMO程序中，它所展示出来了的是一种小巧灵活的一面，但是当你在大量使用的时候，却会发现，它的配置文件会成为你程序的一个很大的负担。程序的初始化速度变慢，时不时节点名称冲突，无法做到强类型，修改SQL语句麻烦等等这些问题会始终陪伴你整个开发维护过程。
还有很多我以前在开发过程中注重配置文件，但是却收到反效果的例子和经验。我并不想数落它们，它们都非常的优秀，是它们促进了我的进步。但我们或许能找到更好的替代，比如Enterprise Library里的Caching可以使用HttpRuntime.Cache，Exception Handling & Logging 可以使用Diagnostics & Health mornitoring，Cryptography可以自己写个简单点的，Security的功能在asp.net2.0已经有Membership了。iBatis.NET或许改为NBear尝试一下。
有些配置文件可能是必不可少的，但至少要么都是系统已有的配置就像Membership 和Health mornitoring一样；要么是有配置文件，但不需我们手工修改的如NBear；要么应该要有配置工具方便配置。
从最开始的不会使用配置文件，到需要维护大量配置文件，再到怕维护配置文件，最后到优先约定，合理使用配置文件，是一个成长的过程。说到这里，似乎有背标题的原意了，毕竟配置≠配置文件。
