关于WebForms以及一些ASP.NET开发上的经验（3）

要复用，一般总需要组件化或模块化，内部实现通用的功能，而具体的信息应该由外部传入。例如我 们上面的计数器就应该进行改造（用到了MS AJAX Lib里的Function.createDelegate方法）：

function Counter(textBoxId, interval)
{
　　this._counter = 0;
　　 this._textBox = document.getElementById(textBoxId);
　　this._interval = interval;
}
Counter.prototype =
{
　　run : function()
　　{
　　　　this._textBox.value = (this._counter ++);
　　　　window.setTimeout(
　　　　　　Function.createDelegate (this, this.run), this._interval);　　　　　　
　　}
};

现在这个技术器的复用性已经有质的飞跃了，因为我们可以随意指定一个客户端的文本框进行显示， 并且可以自由地设置计数器增长的间隔时间。于是我们在WebForms页面中就可以写如下的代码了：

<asp:TextBox runat="server" ID="textBox1" />
<asp:TextBox runat="server" ID="textBox2" />
<script language="javascript" type="text/javascript">
　　new Counter("<%= this.textBox1.ClientID %>", 500).run();
　　new Counter("<%= this.textBox2.ClientID %>", 1000).run ();
</script>

现在WebForms客户端ID污染已经不构成问题了吧！

其实解决客户端ID污染的做法用一句话就能说清：“将不变的部分提取至js文件，将变化的部分（例 如服务器控件的客户端ID）留在页面中”。但是我在这里将它上升到组件化的高度，因为它能让我们开发 出更优秀的客户端程序。组件化的客户端编程方式较之传统的零散function的做法，更有利于代码的管理 ，并且增强了复用性和可维护性。有人说，客户端ID污染问题使脚本代码很难做到“内聚”——可能他的 意思是将脚本代码提取到js文件中吧——但是我认为，这种污染“迫使”我们使用组件化的方式进行客户 端开发，而这种组件化或者模块化的做法恰恰提高了代码的内聚性。

不过，似乎组件化的编程方式会写更多的代码，不是吗？从理论上来说，可能的确是。不过需要注意 的是，我上面提出的例子非常简单，简单到了其中的一半代码是用于“组件化”编程的“骨架”上。而对 于一个略为复杂的功能来说，例如一个通用的表单验证组件，或者客户端级联组件，增加的这点“骨架” 还算得了什么呢？

这也算是一种因祸得福吧。

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!