什么时候用html控件，什么时候用"标准控件"?

Question

从asp转过来
有很多原则性的东西不是很明白
也不是很习惯希望大家多多指教最后有人能提供一下完整的文档方案先行谢过！

Answer 1

其实这没什么好问的, 买本书看看, 就明白了.
一般认为涉及到后台代码的就是WEBCONTROL, 其它用HTML

Answer 2

服务器控件的最终结果也是生成HTML代码返回到客户端的，中间有个编译的过程
所以，在非必要使用的情况，都不用，如Lable，总不能每个文字显示都用它吧

Answer 3

一般你要在后台引用的就用服务器端控件，不然就用html控件

Answer 4

web控件可以在后台方便调用
html只能在客户端脚本中调用  如果要在服务器端调用只需 在html控件中加入runat="server"web控件很难控制样式和布局
html控件很容易控制页面布局和样式  所以一般web控件嵌套在做好样式和布局的html控件中就这么点差别

Answer 5

能不用服务器端控件尽量不用
能用html控件就不要用web控件
服务器端控件效率低

Answer 6

回复人：viena() 维也纳(windows7) ( 四星(高级)) 信誉：100
能不用服务器端控件尽量不用
能用html控件就不要用web控件
服务器端控件效率低
--------------------够明白了

Answer 7

能不用服务器端控件尽量不用
能用html控件就不要用web控件
服务器端控件效率低＝＝＝＝＝＝＝前两句同意，至于后一句，效率上，纯 html 肯定比 runat=server 低，对于 runat=server ，事实上 asp.net 内部帮我们作了许许多多的工作，比如在 asp/php/jsp 中需要 
<input type=text name=MyTextBoxName value='<% =Request.Form["MyTextBoxName"] %>' />
来维护两次post之间的状态而
<asp:textbox/> 帮我们做了这项工作，其内部也是使用 Request.Form 类获取值，然后经过一系列的处理周期（asp.net基于事件驱动）在一个页面上，前者，只是一个字符流的输出，后者涉及对象的创建，控件层次的维护，大量相关页、控件事件同步，ViewState维护比如必然导致额外的性能损耗，但，它带来的是，【开发效率成倍的提升，完整的组件编程模式....】
你不必再一堆的 Request.Form 中绕，你可以引用服务器控件对应，统一的编程模型
如
1.
string txt = Requst.Form["MyTextBoxClientName"];VSstring txt2 = MyTextBoxServerID.Text;2.// js
document.form1.action = "?action=delete"
// aspx.cs
if(Requst.QueryString["action"] == "Delete") {
   // 执行删除操作 ...
}VS // aspx
<asp:Button Click =DeleteButton_Click ...//  aspx.cs
void DeleteButton_Click( ...
{
       // 执行删除
}

Answer 8

VMM,写个for循环显示数据明显没有用服务器控件显示快

Answer 9

那我问下我要在后台代码中从数据库中读取一个字段，在页面上显示，比如放在<div id="name"></div>里边，我可以<%= Name%>,也可以用一个<lable>，这样的话当然是直接用<%= Name%>效率高了，可是我CS文件的其他方法用用这个Name的的值，那么有回发的话name的值就没有了，lable还有值的，主要是lable默认开启了VIEWSTATE。
所以我一般在这种情况下还是用LABLE的，不知道一般你们怎么用？

Answer 10

那么，如何选择？
A.
对于简单控件，如 TextBox CheckBox DropDownList .... 等等与 html form 表单元素直接对应的，假如我们系统维护多次提交之间他们的状态，未尝不可使用之，
至于效率，通常是可以忽略的，另外，你还处于 Win32 前时代迈？B.
对于 GridView/DataGrid/ ...  这样的控件，以以及 TreeView Menu ...， 前者实际上帮我们完成了 asp 中
while '遍历 RecordSet 
Response.Write("<tr><td>...") 
' ....这么一项工作，
同时提供前述的完整的事件模型，便于我们服务器端编程操作【他们最大的诟病就是，假如你启用（默认启用）【ViewState】 来维护状态，
那么你一次绑定显示的数据多，页面的大小会成倍的增长】但是，同时，你也注意到，假如我通过 ViewState 来维护状态了，虽然页面变大了，但是多次提交之间，我不必从数据库再加载这些数据了，因为控件会才自动从 ViewState 中自动恢复ViewState 是通过存储在一个隐藏域来实现的，html input hidden 这是我们在 asp/php/jsp 常用的手段的.....简单的分析之后，你会发现， ASP.NET 就是一个“框架”，包装了很多东西，为我们建立了一个统一的 Web 开发模型， 这个模型最重要的就是，事件驱动——将客户端事件映射为服务器事件，进而实现类型 Win App 的开发模式！ASP.NET 有太多的特性，没有办法三言两语说清楚，
至于性能，你不能简单的说，用服务器控件，效率就低，
控件一般是给非专业人士准备的，就是只会拖动鼠标的那些人，专业开发人员很少用的；
＝＝＝＝＝＝＝＝＝＝
高手不见得就不用，runat=server， 一个性能优良的应用系统，是需要综合各方面的设计策略的，
从ASP迁移的过来的，多数会对 asp.net 产生疑惑，但是相信，具有传统web开发经验者，能够很快，理解其本质，了解其内在运行机制，不管如何，他们都离不开最原始的 Requst/Response 这两个对现象！
系统性能 与 开发效率 需要一个 tradeoff 的过程，
毕竟，我们已经不在3.5英寸盘的时代，2004 年末我加一条256内存的是，240￥，还是现代的
现在 512 的多少 1G 的多少？
从应用系统类型看，
除了，门户型的信息类网站之外（他们更多使用静态页），简单服务器控件可以放心使用，重量的服务器控件，根据设计策略而定
另外，假如基于纯 AJAX ，那看什么框架了，轻量基本的如 AjaxPro，也就没有必要服务器控件了，通过 js + DOM+ dhtml 基本可以完成 UI 绘制了
Hope helpful!

Answer 11

Jinglecat说的非常到位。支持。我在这里提供一个参考文章，希望对楼主有用《谈谈HtmlControl与WebControl的区别与用途 》http://blog.csdn.net/octverve/archive/2007/09/04/1771114.aspx

Answer 12

@octverve哈哈，你即时编译（编辑），按需推出文章啊？太多的东东，没有办法三言两语说清楚，我也是说得，丢三落四，总之呢，假如是大型系统，UI 层上性能提升不大，UI 层我们应该更加考虑的是【用户交互友好性】，如能够不必要 PostBack 尽量不要，但是也不要走向 AJAX 的极端，性能关键还是各种“策略”，比如数据库设计，数据缓存，当然 asp.net 也为 UI 层提供了【缓存机制】，这也是优于 ASP 的一大亮点，都说 asp.net 性能够不如 asp，
那是因为，他们没有充分的挖掘 ASP.NEt 的各种特性，以为，三下五除二，托几个 GridView + xxxDataSource 就象做企业应用，当然“拖拽”方式，对于小型应用，足够应付！

Answer 13

从asp转过来
有很多原则性的东西不是很明白
也不是很习惯
===================
人家LZ刚转过来``
对错放一边~~上面叫人家少用WEB控件的,你也不看对象,人家刚转过来唉~~说那些没用的干嘛~~?!!
纯扯淡~~哪个初学的不是先托控件``
自己NB也不能误导别人,何况不NB.

Answer 14

＠Jinglecat现打字的话，有可能说不全，所以先收集了一些可能被经常问的文章，到时，一指路就行，哈哈你老兄的，government　项目如何了？如何赚了大家，不要望了，请我喝酒啊。

Answer 15

Jinglecat说得不错！
顶你！

Answer 16

//写个for循环显示数据明显没有用服务器控件显示快
方法有问题~

Answer 17

我是楼主
首先谢谢大家的回复感觉html控件似乎是为js设计界面专用的
然而想再延伸一下
<asp:TextBox  onmousemove="alert('Hi,你好!');" />
<input type="text" runat="server" onmousemove="alert('Hi,你好!');" />
<asp:TextBox  />
<input type="text" runat="server">四者的话
又该怎么理解呢
即使是服务器端控件也照样也可以响应js事件
而html控件加个runat="server"与服务器端控件又有了什么区别？

Answer 18

而html控件加个runat="server"与服务器端控件又有了什么区别？
=====
服务器端控件是微软特意开发出来的，他的功能和一般的 html控件不一样的...比一般的html控件多，但是最终还是会转换为html控件.html加个runat=server 可以在服务器端后台进行调用,也具有服务器端的一些特性 比如viewstate

Answer 19

也是个人习惯问题我习惯用UserControl而不习惯用MasterPage习惯用HTML控件，一般情况下不使用服务器控件(Repeater,DataList还是很常用的)尤其反感ViewState

Answer 20

任何编程模型都有常见的性能缺陷，ASP.NET 也不例外。本节描述一些可避免在代码中出现性能瓶颈的方法。 在未使用时禁用会话状态： 并非所有的应用程序或页都要求基于每个用户的会话状态。如果不需要，可将其完全禁用。这可以通过以下页级别指令轻松实现： 
<%@ Page EnableSessionState="false" %>注意：如果页需要访问会话变量但不创建或修改它们，请将指令值设置为 ReadOnly。还可为 XML Web 服务方法禁用会话状态。请参阅 XML Web 服务一节中的使用对象和内部对象。 
慎重选择会话状态提供程序： ASP.NET 为存储应用程序的会话数据提供了三种不同的方法：进程内会话状态、作为 Windows 服务的进程外会话状态和 SQL 数据库中的进程外会话状态。每种方法都有自己的优点，但进程内会话状态是迄今为止速度最快的解决方案。如果仅在会话状态中存储少量易失数据，则应使用进程内提供程序。进程外解决方案主要用于 Web 花园和 Web 农场方案，或用于当服务器/进程重新启动时不能丢失数据的情况。 避免与服务器间的过多往返行程：Web 窗体页框架是 ASP.NET 的最佳功能之一，因为它可以显著减少为完成某项任务所需编写的代码量。使用服务器控件和回发事件处理模型的页元素编程访问无疑是最省时的功能。但是，对这些功能的使用存在着适当和不适当的方法，了解何时使用它们是适当的很重要。 
应用程序通常仅在检索数据或存储数据时才需要往返于服务器。多数数据操作可在往返行程间在客户端进行。例如在用户提交数据前，通常可以在客户端验证窗体项。通常，如果不需要将信息中继回服务器，则不应往返于服务器。 如果编写自己的服务器控件，请考虑让它们为上级（支持 ECMAScript）浏览器呈现客户端代码。通过采用“智能”控件，可显著减少对 Web 服务器的不必要点击次数。 
使用 Page.IsPostback 避免往返行程上的额外工作：如果处理服务器控件回发，通常需要在第一次请求页时执行代码，该代码不同于激发事件时用于往返行程的代码。如果检查 Page.IsPostBack 属性，则代码可按条件执行，具体取决于是否有对页的初始请求或对服务器控件事件的响应。这样做似乎很明显，但实际上可以忽略此项检查而不更改页的行为。例如： 
<script language="C#" runat="server">    public DataSet ds;
    ...    void Page_Load(Object sender, EventArgs e) {
        // ...set up a connection and command here...
        if (!Page.IsPostBack) {
            String query = "select * from Authors where FirstName like '%JUSTIN%'";
            myCommand.Fill(ds, "Authors");
            myDataGrid.DataBind();
        }
    }    void Button_Click(Object sender, EventArgs e) {
        String query = "select * from Authors where FirstName like '%BRAD%'";
        myCommand.Fill(ds, "Authors");
        myDataGrid.DataBind();
    }</script><form runat="server">
  <asp:datagrid datasource='<%# ds.DefaultView %>' runat="server"/><br>
  <asp:button onclick="Button_Click" runat="server"/>
</form>
Page_Load 事件对所有请求都执行，因此检查了 Page.IsPostBack，以便在处理 Button_Click 事件回发时不执行第一个查询。请注意，即使没有此检查，页的行为也不会改变，因为第一个查询中的绑定会被事件处理程序中的 DataBind 调用推翻。记住，在编写页时会很容易忽略这个简单的性能改进。 谨慎适当地使用服务器控件：尽管服务器控件使用起来非常容易，但它并不总是最佳选择。许多情况下，简单的呈现或数据绑定替换可以完成同样的事情。例如： <script language="C#" runat="server">    public String imagePath;
    void Page_Load(Object sender, EventArgs e) {
        //...retrieve data for imagePath here...
        DataBind();
    }</script><%-- the span and img server controls are unecessary...--%>
The path to the image is: <span innerhtml='<%# imagePath %>' runat="server"/><br>
<img src='<%# imagePath %>' runat="server"/><br><br><%-- use databinding to substitute literals instead...--%>
The path to the image is: <%# imagePath %><br>
<img src='<%# imagePath %>' /><br><br><%-- or a simple rendering expression...--%>
The path to the image is: <%= imagePath %><br>
<img src='<%= imagePath %>' />在此示例中，不需要服务器控件将值代入发送回客户端的结果 HTML。在许多其他情况下此方法同样适用，甚至在服务器控件模板中。但是，如果要以编程方式操作控件属性、从中处理事件或利用其状态保存，则服务器控件更合适。应检查服务器控件的使用，并查找可优化的代码。 
避免过多的服务器控件视图状态：自动状态管理是一种功能，它使服务器控件能够在往返行程中重新填充它们的值，而不要求编写任何代码。但是，此功能并不能任意使用，因为控件状态是在隐藏的窗体字段中传入和传出服务器的。应当明白 ViewState 何时有帮助，何时没有。例如，如果在每个往返行程中将控件绑定到数据（如第四条提示中的数据网格示例所示），则不要求控件维护它的视图状态，因为无论如何都将擦除任何重新填充的数据。 
默认情况下，为所有的服务器控件启用 ViewState。若要禁用它，请将控件的 EnableViewState 属性设置为 false，如下例所示： 
<asp:datagrid EnableViewState="false" datasource="..." runat="server"/>还可在页级别关闭 ViewState。这在根本不从页回发时非常有用，如下例所示： 
<%@ Page EnableViewState="false" %>注意，User Control 指令也支持此属性。若要分析页上的服务器控件使用的视图状态量，请启用跟踪并查看“控件层次结构”表中的“视图状态”列。有关跟踪功能及如何启用它的更多信息，请参阅应用程序级别的跟踪记录功能。 对字符串连接使用 Response.Write：在页面或用户控件中对字符串连接使用 HttpResponse.Write 方法。该方法提供非常有效的缓冲和连接服务。但是，如果您打算执行大量的连接，则使用下列示例中的方法（即多次调用 Response.Write）来连接字符串比仅调用一次 Response.Write 方法要快。 Response.Write("a");
Response.Write(myString);
Response.Write("b");
Response.Write(myObj.ToString());
Response.Write("c");
Response.Write(myString2);
Response.Write("d");
不要依赖代码中的异常：异常非常浪费资源，应在代码中尽量避免。绝不要将异常作为控制常规程序流的方法。如果可以在代码中检测到会导致异常的条件，就应该那样做，而不要等到捕捉异常后再处理该条件。常见的方案包括：检查空值，分配给将分析为数字值的字符串，或在应用数学运算前检查特定值。例如： // Consider changing this:try {
   result = 100 / num;
}
catch (Exception e) {
  result = 0;
}// To this:：if (num != 0)
   result = 100 / num;
else
  result = 0;将大量调用的 COM 组件移植为托管代码：.NET 框架一种非常容易的方法与传统的 COM 组件相互操作。其优点是可以在保留现有代码的同时利用新的平台。但是，在某些情况下，保留旧组件的性能成本超出了将组件迁移到托管代码的费用。每种情况都非常特别，而决定所需更改的内容的最佳方法是测量站点的性能。但是，通常 COM 交互性的性能影响与函数调用的次数或从非托管代码封送到托管代码的数据量成比例。由于各层间的通讯数，需要同大量调用交互的组件称为“chatty”。应考虑将这种组件移植为完全托管的代码，以从 .NET 平台提供的性能收益中获益。或者可以考虑重新设计组件，以请求更少的调用或一次封送更多数据。 将 SQL 存储过程用于数据访问：在 .NET 框架提供的所有数据访问方法中，基于 SQL 的数据访问是生成性能最好的可缩放 Web 应用程序的最佳选择。使用托管 SQL 提供程序时，可通过使用编译的存储过程而不是特殊查询，获得额外的性能提高。有关使用 SQL 存储过程的示例，请参考本教程的服务器端的数据访问一节。 使用 SqlDataReader 获得快进只读数据游标：SqlDataReader 对象对从 SQL 数据库中检索的数据提供前进只读游标。如果 SqlDataReader 适合于您的情况，则它是一个比 DataSet 更好的选择。因为 SqlDataReader 支持 IEnumerable 接口，甚至还可以绑定服务器控件。有关使用 SqlDataReader 的示例，请参阅本教程的服务器端数据访问一节。 尽可能缓存数据和输出：ASP.NET 编程模型提供了一个简单的机制，在不需要为每个请求动态计算页输出或数据时缓存它们。在设计页时可以考虑用缓存来优化应用程序中那些预期有最大通信量的地方。适当地使用缓存可增强站点的性能，有时甚至可以增大一个数量级或更多，这是 .NET 框架的任何其他功能无法企及的。有关如何使用缓存的更多信息，请参阅本教程的缓存服务一节。 为多处理器计算机启用 Web 花园：ASP.NET 进程模型帮助在多处理器计算机上启用可缩放性，将工作分发给多个进程（每个 CPU 一个），并且每个进程都将处理器关系设置为其 CPU。该技术称为 Web 园艺，它可以显著提高某些应用程序的性能。若要了解如何启用 Web 园艺，请参考使用进程模型一节。 不要忘记禁用调试模式：ASP.NET 配置中的 <compilation> 节控制应用程序是否在调试模式中编译。调试模式严重降低性能。在部署生产应用程序或测量性能之前，始终记住禁用调试模式。有关调试模式的更多信息，请参考题为 SDK 调试器的章节。

Answer 21

只是为了显示数据的时候 尽量使用html控件以减轻服务器负担 ，如果要涉及和服务器打交道一般使用服务器控件，html控件配合脚本使用也能达到服务器控件一样的效果

Answer 22

为 ASP.NET 应用程序启用调试模式
由于 ASP.NET 框架应用程序的许多部分是在运行时动态编译的（例如 .aspx 和 .asmx 文件），所以必须先配置 ASP.NET 运行库以使用符号信息编译应用程序，然后才能调试该应用程序。符号（.pdb 文件）通知调试器如何查找二进制文件的原始源文件，以及如何将代码中的断点映射到那些源文件中的行。若要配置应用程序使用符号进行编译，请在应用程序根目录下的 Web.config 文件的 system.web 组中，在 compilatio 节上包含 debug 属性，如下所示： 
<configuration>
  <compilation debug="true"/>
</configuration>重要事项：应该仅在调试应用程序时才启用此设置，因为它会显著影响应用程序的性能。