.net非控件式编程的优越性

.net非控件式编程的优越性2010-12-29cnrui Clear上个月头因为幻想曲同志的的造访,使得VIEW进入了重构期。将原有的架构全部推翻，使用标准的工厂三层模式，代码全部重写，加入缓存依赖，简化存储过程，改进整个项目的容错机制，等等。

整整一个月的奋战总算是重构完成，在重构中仍然保持不使用框架，不使用可视化控件。其实在重构之前有些朋友强烈推荐我使用 EnterpriseLibrary, 以及 Nhibernate 作为数据访问层框架。不过抱着学习底层知识的态度，我没有使用，一切方法都是纯手工打造。

在重构中最头疼的就是写实体层（valueobject），都是些简单而繁琐的事情，手都快搞疼。还好幻想曲推荐了李天平代码生成器，自动生成工厂三层模式你所需要的代码，一下效率就提高了几倍。

在VIEW重构尾期，我接手公司一个.net项目的表现层优化。当我打开VS后，看到整屏的控件，头大了。首先下手的就是改进Webpart，在中间发现一个微软严重的BUG，就是在代码生成后，有个TD里面的CSS属性Padding:5px根本没办法改的动，微软也没有提供任何方法或属性。差不多搞了三天，终于在微软的MSDN里面看到一个老外非常愤慨地责备微软的这个BUG，而微软也承认这个是个问题，并承诺在下个版本进行改进。于是就这样浪费了我三天时间。

不过在这三天里却熟悉了微软的控件式编程方式，个人感觉确实很好用，微软也确实为开发群体想到了很多的问题。但是这种编程方式只能象微软说的那样，在企业化快速开发中使用，真正想搞那种高质量产品开发过程，我奉劝别用微软的那套方法。因为目前看到的是，在项目开发上面确实很迅速，但是在维护以及改进方面，根本就会加重负担，反倒让整体进度拖慢。

因为在使用控件式编程中，存在太多的不稳定因素。表现层和其他的层次最大的不同，在于它所面对的是最终用户，而其他层次所面对的只是开发人员。所以在技术上后面的层次发展已经十分稳定，而表现层本身有着无尽地变化，我们不能过于追求模式化的开发，而忽略表现的本身。

而非控件式编程在开发期间的效率肯定很低下，但是对于后期的维护与改进却非常的便利。至少我不会因为一个不成熟控件的BUG而需要找上几天的问题，然后再继续期待这个控件更新版本，当版本更新后，又要冒着新BUG出现的风险。而所以控件自定义的话，就绝对没有这个问题存在。

我会花很多时间写表现层控件，但是对于一般的开发团队来说是非常勉强的。所以最近不是提出了前端架构师这个概念吗？我想，一个高质量的项目开发里面，应该考虑前端架构师的位置，让前端技术与后端技术保持同样的等级。

千万不要忽视这个想法，项目使用控件编程方式（主要是指使用可视化控件），越往后，只能越来不受欢迎，会越多的给项目增加维护成本。

可能有些喜欢挑刺的麻烦人物会说，你要实现这么多东西，那么你干脆自己写个语言好了。呵呵，这样的人很无知和幼稚，请不要在我这里做愤青，我是会删这些留言的，请不要浪费精力和我理论这个，因为我前面就说了，表现层之外的技术已经非常成熟，基本上就算改动，也会保持向下兼容，但表现层想真正做到向下兼容，绝对不可能的。至少我看到微软目前在表现层做的所谓向下兼容，都是通过JS去动态改变一些错误的默认属性。这样的方式你会接受吗？