来到新公司，接触新项目，傻眼了。
居然还是asp.net webform的项目！过去2年，我已经慢慢习惯了asp.net MVC。而开发工具，还是VS2010!
真是恍如隔世，难道时光倒流，回到了5年前？
看看项目的具体情况，感觉更糟糕：
1、可能是历时长久，维护者众且人员更迭，代码也没有严格要求，各种备份包、说明文件随意放在工作目录，有修改的话，代码或文件就复制粘贴，新老文件并存。究其原因，猜测是接手的人怕改错了，于是复制原文件重命名后进行修改，但原文件并没去掉，只是将链接路径改为新文件。另外像JS、image、CSS的冗余就更严重了，不管有用没用，不管是否已经存在，分散于里里外外的各个目录中，这里放一点，那里又放一点，甚至images目录下还有CSS、JS的，一切只图当时方便。一个WEB项目，居然有16000+个文件，拷贝、编译都相当耗时。我的感觉是，失控了。
2、代码不分层，直接在页面代码里书写SQL语句。本来WEBFORM就容易出现页面逻辑、呈现代码混杂的弊端，现在好了，跟数据库也耦合在一起了。
“我好想改为MVC”，公司里资深的程序员说。
这固然是好，但，时间允许吗？
1、耗费那么多时间，转为MVC，但功能还是那些功能，从外行的角度看，似乎什么都没变，别告诉公司高层和客户说，你看，现在代码逻辑很清晰这样的鬼话
2、转为ASP.NET MVC，意味着以前积累的WEBFORM控件、代码很多都用不上了
3、从我自身经历来看，对习惯于WEBFORM的程序员来说，转为MVC，要经历一段相当迷惘、痛苦的适应过程
目前比较现实的做法是，在新项目中进行有限、渐进式重构。这个新项目，是在旧项目的拷贝上进行修改：
1、尽可能地采用MVC。推倒重来，改为ASP.NET MVC是不可能的。但是，MVC是一种思想，而ASP.NET MVC只不过是微软实现了MVC的一个开发框架。采用MVC，不等于一定要选用ASP.NET MVC。
MVC的精髓在于呈现和数据、逻辑分离。数据的话，增加专门的数据处理层，与逻辑分离不成问题；只是ASP.NET WebForm模式下，很容易将呈现和处理逻辑混杂在一块。
既然如此，应该尽量将逻辑处理抽离出来，放在独立的逻辑处理层（BLL）上。并且要面向接口编程，即页面代码使用接口进行调用，方便以后重用为其他项目。
在ASP.NET MVC中，有时会有若干个控制器共用一个视图的情况，这对提高重用无疑很有用。
而WEB FORM里面，怎么做到这一点？可以采用MVP模式，即将页面处理部分抽离出一个接口，然后用类来实现这个接口。雷同的页面，都使用这个接口，依赖注入这些类。
它与ASP.NET MVC的区别只在于，前者还是要提供多个视图，而后者只须一个视图。但对前者来说，代码量已经精简不少了。
但如果没有这些页面雷同的情况，就不必矫枉过正，过犹不及，陷入过度设计。
2、尽量规整代码，将JS、CSS、图片整理，集中存放，自不在话下。
版权声明：本文为博主原屙文章，喜欢你就担走。