摘要：
前两天同事讲解他编写的快速开发模型，他把现实中的不同功能的ASP.NET页面归类，然后根据不同情况实现了相关的模板类；当你需要某此功能时从相关模板派生出来然后重写某些成员很快就能完成（如某行为的Button,或数据编辑Entity来源）。在他演视时并没有看到他编写业务逻辑，于是就好怪地问他是如何处理的；原来在每个类别的页面模板内部都捆绑数据处理功能，他试图在模板类中完成所有数据处理的情况和相关业务逻辑规则。当然这情况我是非常反对的，因为随着业务的变更模板类就会变得臃肿难以维护，最后可能出现更糟的事情!当我提的一大堆面对的问题后确被一个很直接的答案了结了“快速开发”，的确真的很方便对于他描述的例子，我也不能否认！
其实同事的方案是很好的，能使开发人员够遵循一个规则并进行快速开发。只是有一点我是很不认同的就是UI、BLL和DAL捆绑在一起，集中捆绑对代码的修改和维护都是致命的；何况修改和维护的时间往往比开发的时间要长，相应的成本就更高!除非能保证代码能适应所有情况，这显然是不太可能...
阅读全文
2006年9月18日
