完全放弃dreamweaver设计方法的几个理由
说明：
dw=dreamweaver(mx,mx2004 or 8)
vs=visual studio 2005
以前我在博客里写到用dreamweaver和visual studio一起写bs是很爽的事，但是我现在觉得vs2005是完全可以代替dw的。也会有很多人认为用dw做模板然后用vs写业务逻辑不是很好吗？但是针对dw里的一些缺点，并且xhtml的出现，vs完全取代dw还是有可能的。
dw和vs是大家在开发bs程序使用的比较多的两个工具，本人也是从dw逐渐正在转向vs的，针对两者在设计上的区别，总结如下。
dw系列的设计操作是面向每个html标记的，讲究对每个html标记的理解，比如我们做一个类似datalist的东西，我们一般是选中要被repeat的行<tr>，然后在“行为”里选择”repeat”功能，再指定一个预先生成好的一个dataset就可以根据此数据集循环来生成一个类似datalist的东西（实际上dw里是封装了<ASP:Repeater>来实现的，然后选种的内容就自动的变成了里面的<ItemTemplate>），而vs的操作是面向framework下的web control和html control，这个大家都知道，当然也有面向html的直接操作，我觉得这是两个软件在设计思想上最大的不同，在前者的身上能看早早期设计大师的身影，而后者更讲究对对象和类的理解。
dw也支持对诸如datagrid(v1.1)的操作，但是对其custom的程度是相当的弱的了，不知道是因为被收购还是macomedia的主要精力已经投入到其自己的bs技术上，对于其它bs技术的开发（asp,asp.net,jsp,php）只是通过拖拽实现一些简单的数据操作，而复杂的业务逻辑还是要靠vs来完成，这也是我要逐渐放弃dw而完全转向vs的原因。虽然说dw的拖拽操作可以快速的完成，但是custom的操作太弱了。
还有一个很要命的地方，就是dw居然不支持验证控件。比如我们利用dw下Application下创建了一个插入数据的form,加入一个输入验证是很正常的，而此验证控件在dw生成的数据插入form下是不会work的，想要实现一种数据验证我要被迫去写以前在asp下用的一个javascript，而有时候text属性弄不好的话javascript又不工作了。
dw下的数据插入操作
另外，根据xhtml1.1的标准，在设计界面上两者也有很大的区别，比如说，在dw下，我做一个<table>那么在design模式下下面的属性框里，我们设置的有些属性比如width,height和bgcolor等是用正常的描述方法
<table width=xxx height=xxx bgcolor=xxx>
来描述的，而我们知道这种描述方法在xhtml1.1的标准里已经不可行了，在vs2005默认设置下编译程序会发现提示错误说在xhtml中有更好的方法来替代width和height了，如下图：
在vs下给出的xhtml1.0验证提示
有很多朋友遇到这个问题，其实我们可以设置一下不让vs用xhtml的校验方法，设置方法是在Tools-options里把默认的XHTML1.0 Transitional选成其它的就可以了。
设置vs不对xhtml的验证
但是本人不建议这么做，所以这也是我想完全放弃dw的原因之一，其实在vs下画一个<table>，在属性里有个styles它里面集成了一个css样式编辑器，大部分的css设置在里面都有，所以通过它我们完全可以编写出符合xhtml的代码。
vs下设置<table>的一个操作
其实要说开发效率的话，dw的拖拽确实很快捷很容易学也很直观，但是vs2005对一些新类的封装开发起来还是很快的，因为加入一个datasource然后再用一个datalist最后再edit一下其template如果熟练的话做出的效果和效率我个人认为是远比dw做出的高的，当然还要考虑到以后的代码可读和可维护性。
总之，对于新技术新特性的需要我个人认为抛弃dw来做是完全可行的，需要多掌握的只是一些关于css在vs下的设置技巧，当然了，web control需要熟悉很多的新属性（比如webpart,算是很多的了吧），但是掌握了是很有用的，在开发效率上我觉得不会比单纯的用dw差。