界面层设计模式的困惑

Question

asp.net现在大部份人都采用新的驱动式编程，但也仍有一部份人使用原来的混编方式。在这里也不能说明哪一个更好，各有优点(当然这里说的只是界面层)现在的问题是在开发过程中，用户对驱动式这种比较反感，原因是太多的回发闪屏、操作性差(程序员偷懒和不熟悉js造成的)、响应性下降，而且面对服务器/自定义控件，美工人员也感到无赖。如果用混编方试编写界面层的话，那么原来的驱动式程序员就不好定位。大家有何高见，帮帮我。

Answer 1

在技术上来讲，不管是c#还是vb.net大家应该都互相知道点，即是一个语言的程序员生病不能上班，那么另一个也可以修改项目。但，界面这个东西确实不好弄，可以说做混编的一般就不会用服务器控件，用服务器控件的大多搞不清html和js。.................

Answer 2

混编就是初学者学的？用混编就不如用asp?

Answer 3

.net是时代发展的产物
asp.net的编程模式确实大大提高了效率方便了程序员
但是可能在性能上有所损失（比如视图状态占用过多带宽）

Answer 4

这里也没说讨论.net的编程模式，现在是遇见象我提出来的这种问题。有什么有效的解决办法。

Answer 5

从ASP的inline code 编码到ASP.NET的code behind把显示与编码分开，从前者的顺序执行到后者的event-driven，从前者的解释到后者的编译，这些都是很大的进步，但也带来了新的开发方式，但新的东西总有一个学习/熟悉的过程，如果你的程序员/美工认识不到这些，而且不想学习，不想进步的话，那么也没什么好的办法

Answer 6

我公司转型asp.net一个月马上回转做aspasp.net赚不了钱

Answer 7

PostBack、ServerForm和ViewState说实话，给我的感觉就是非常不成熟的技术。真有够乱的，但也够傻瓜的。如果写WebForm，不需要了解HTML和JS，像WinForm一样拖几个控件处理一些简单的事件，那还叫什么Web开发。HTML是描述UI最好的语言，到了Longhorn，甚至WinForm都会把UI用类似HTML的XAML来描述，ASP.NET这种类WinForm的设计方式是不是一种倒退？默认所有的控件都启用ViewState，不论其是否需要，DataList等控件默认会把数据源整个扔到ViewState中！什么事件会引发回发也没有明确的提示，在事件触发时，Page_Init和Page_Load里面的代码执行否，需要注意什么问题也没有说清楚，ServerForm只能本页提交且具有唯一性，，，，总让人感觉过分傻瓜，过分臃肿和缺乏修改的余地。到了ASP.NET 2.0中，这些东西都会有些改善，例如ServerFrom支持向他页提交，回发处理将使用XMLHttp（这才能接受啊）等等等等。。从这也能看出ASP.NET的WebForm中的很多技术的不成熟。总之，我现在是尽量不使用ASP.NET的这些技术，等他们成熟了再说。尤其是那些数据绑定控件，没几个好使的，我都用自己写的数据绑定控件。

Answer 8

我个人设为两头为难。用新技术的人就知道拖控件，可以说连基本的html都搞不清楚，以至于页面做得七凌八乱，更不用说写js以迎合一些特殊的需要。一般都在后台编码添加一些table的row这种，这又需要与美工多次协商得到最后的订版，来来往往实际上比混编的开发效率更低下。采用混编能解决很多问题，但的确是代码太乱。用新技术又产生更多的问题，不过好维护。鸡肋。
是否是现在的技术如楼上所说不够成熟，还是不应该太过关心界面上的编码。从asp转向.net几年，这个问题一直没有得到很好的解决。

Answer 9

楼上的，试试自定义控件+正则我从未用过混编，但也极少用ServerForm

Answer 10

怎么说呢,我认为楼主的话不无道理.但我想微软肯定也看到了这些问题的存在,随着新版本的ASP.NET出台,相信会得到更好的解决.如果一个开发人员只懂拖拖控件而不能理解HTML为何物,我想这不太现实.

Answer 11

我觉得还是员工的水平不足造成的，没有HTML和JS基础做WEB开发程序员是明显不合格的
要么换人，要么培训

Answer 12

对啊。正如楼上所说，连html和js都搞不清楚的人怎么叫做web开发呢。当然我也不否认控件的好处，但现在的却有好多不懂的人就知道拖控件。要找两样都懂的人十再不是太多。