09年，5，6个人开发一个产品。web页面这块的功能实现差不多全是我做的。由于产品的特殊性，从一开始就没有去找网络上已有的web界面做参考，而是拿着c/s版的前代产品和国外一个同样是c/S版的操作手册截图做模仿。不可否认，桌面程序的友好性和操作效率，b/s是赶不上的。一边模仿桌面程序操作的便利，一边要遵循web的操作习惯，比如在右键菜单，是否该使用，和代替方案，折腾很久。
没有专业的UI工程师，有一套dev控件。摆在面前的资源就这么多。毫无例外的一开始陷入功能的实现中，带着对花钱买的控件的信任，和对时间紧迫的压力，弄出了第一个demo。这个时间段内，以及开始对dev的性能产生怀疑，后来，带着可能是不熟悉它的解释，决定继续用下去。这样，更多的页面，更多的功能出来了。
再到了一个阶段，这时候发现，dev确实是影响了效率。中间很它搏斗很久，通过再找第三方控件，自己写，逐步减少了dev控件的使用。最终，仅仅在不经常使用同时有复杂的功能的页面，或者简单到只用来展示数据的页面保留了dev。期间的调整代价是巨大的。
这里得到一个结论，一个好的控件，必须包括如下功能：
1，客服端操作，既是包含直接可操作的js对象。
2，服务端只需要在!IsPostbakc时绑定一次即可。
3，事件支持，客服端和服务端可以同时相应一件发生在客户端的事情，但是客服端优先，且客户端能决定要不要再传到服务端处理。
4，局部刷新，控件必须独立支持自己的刷新。
5，样式比如大小，位置，支持客户端js编程设置。
对于控件的选用顺序，我想是这样的：原生html标签-》asp.net控件-》第三方控件。
也许你有钱，能买控件，但是这容易诱惑你犯错。控件都是成套的，有自己的主题，要用就得成套的用，不然什么控件都用用，难以控制样式。而成套使用了，毫无疑问，会影响效率。
最终服务器端都是生成文本流给浏览器来解析，所以，b/s开发实际也可看成是浏览器/服务器式的c/s开发。一般来说c/s中的客服端，在显示后，界面上的可见元素，全是自己负责的。b/s开发，最容易，也最不该的是老想通过refresh，reload刷新页面。服务器端既要考虑页面可见元素，又要考虑业务，开发，维护，执行效率都低。
理想的开发模式是这样的，一次仅仅把初始化页面时的必须元素（包括页面可见标签和数据）传送到客服端。以后客服端和服务器端交流的都是数据，客服端全权负责界面的更新。没有什么Postback来刷页面。
目前的控件，都提供服务器端属性设置，再有页面状态缓存与还原，再各种入门，高级，揭秘等等教导的大都是一切控制，尽在服务器。促使很多人练手的时候，觉得好好的。等实际用于商业的时候，就满足不了了。是的，我是这么受害的。
这样的开发模式，需要大量的js代码，但是绝对值得。这么多的js代码，要求我们用开发服务器端得高度去看待它。是的，开发服务器端的思想都用上，面向对象，设计模式，等等等，不再把它当做辅助性的脚本语言。定义好与服务器交互数据的协议，包括，客服端传传出的文本里怎么标记请求名称，请求参数，是否需要返回值。服务器返回文本包括成功与否，数据等信息。