「置顶」C# 学习的前景
①目前有多少人在学习C#中②「编程论坛」冷清的残酷现实
③C#学习的具体应用？
④学C#的职业前景？
⑤俺是菜鸟，希望大虾指点迷经，也提高下广大C#烧友的热情
⑥强烈要求提升「编程论坛」人气，希望广大C#友宣传下
⑦因为喜欢，所以停留，因为停留，所以更喜欢这里
新手就提出了这么严重的问题！
残酷的现实是该注意了，我就是学c＃的，真的不知道它的前景会是什么样子的？
2005-10-11 09:07
2005-10-11 12:21
2005-10-11 14:08
2005-10-12 15:14
2005-10-12 23:20
2005-10-18 22:32
2005-11-26 01:30
微软本来只需要对Web应用平台ASP作稍加改进，比方提供一个功能更强的服务器端脚本编程语言或者页面编译功能就可以保持或者甚至提高ASP的流行度。实际上ASP.NET提供了这两个功能--但是它还提供了更多的东西。简单的说，ASP.NET是一场革命。在本文中，我将讨论ASP.NET对于Web编程所做的提高。
在ASP模型中，一个页面是通过HTML定义然后是通过嵌入的脚本扩展的。在ASP.NET中，不同的是，一个页面是一个生成HTML的类。这个模型被称为WebForm。如果这个名字让你想起VB6的表单控件或者.Net WinForms，那么你摸到点边了。对于WebForms来说，Web服务器控件都放在一个页面上。当这个页面被访问的时候，这些控件自动将它们以HTML的方式实现。浏览器和服务器之间的复杂过程对程序员来说是透明的，由服务器自动完成，并允许事件处理，就和WinForms一样。
欢迎页面
让我们马上开始创建一个叫Greeter（欢迎者）的例子然后看看它是如何工作的。我在学习一个新技术的时候喜欢将它们拆开然后再凑成一整块。Greeter仅仅是要求用户输入一个名字然后发出一条问候消息，但是它演示了ASP.NET的几个主要特点。
Greeter页面定义在两个文件中：Greeter.aspx，在列表A中，和Greeter.aspx.cs，在列表B中。.aspx文件定义了页面的UI（用户界面），而C#文件（你也可以使用Visual Basic.Net或者 JScript.Net）在GreeterLogic类里实现了这个页面的逻辑。Greeter.aspx文件第一行的@Page指令通过继承将UI绑定在程序逻辑上。这个指令中的ClassName属性将UI类的名字指定为CreeterUI。而Inherits属性指定GreeterUI是从GreeterLogic继承而来的。
Web服务器端控件
在这个页面的<form>置标中申明了几个Web服务器端控件。Web服务器端控件是标准HTML置标的WebForm抽象化。它们与标准的HTML相比能够提供事件处理并生成更多的功能。Web服务器端控件在一个引用asp命名空间的XML置标里被申明。.aspx文件中的每一个Web服务器控件在页面被执行的时候会导致控件的一个实例被创建。对每个实例的引用在其相应的基类中被保持。这便使得基类能够访问这些控件并能够让它用程序控制这些控件并处理这些控件产生的事件。每个Web服务器端控件指定属性runat="server"来表明这个控件在Web服务器端运行以便为目标Web浏览器生成合适的HTML。
最开始的三个Web服务器端控件是相当直观的：标签控件（label），文本框，和一个提交按纽。最后的一个控件，<asp:RequiredFieldValidator>，是不同的。一个验证控件检查另一个控件的状态并且当目标控件没有处于正确状态的时候会阻止这个表单被提交。在Greeter这个程序中，RequiredFieldValidator控件被用来验证一个数据是否已经被输入到了文本框控件里。它并不关心这个数据的值是多少。初始状态下，RequiredFieldValidator控件是不可见的。如果在按纽被单击的时候文本框是空的，那么就不会产生单击消息，而且RequiredFieldValidator控件会显示ErrorMessage属性的属性值，如图B。对于高版本的浏览器来说，RequiredFieldValidator控件生成JavaScript以在客户端进行数据验证。而对于低版本的浏览器来说则需要在服务器端进行验证。ASP.NET除了RequiredFieldValidator控件外还提供了几个验证控件。
GreeterLogic类
GreeterLogic从类System.Web.UI.Page继承而来。它申明了几个protected数据域来保存对Greeter.aspx文件中创建的控件的引用。GreeterLogic定义了两个方法。OnInit方法重载了方法Page.OnInit来为m_Button单击事件添加一个m_Button_Click方法的代理。m_Button_Click方法处理由m_Button Web服务器端控件生成的单击事件。这个单击事件触发一个到服务器端的数据发送过程。在服务器端，ASP.NET重新生成这个页面然后恢复WEb服务器控件的状态。现在文本框的值就可以通过访问TextBoxText属性得到了。
要配置Greeter应用程序，你可以遵循下面的步骤：
创建一个应用程序的目录。
在应用程序的目录里创建一个bin子目录。
把Greeter.aspx放在应用程序目录里。
使用命令csc /t:library /out:Greeter.dll Greeter.aspx.cs把Greeter.aspx.cs编译成一个库文件然后把Greeter.dll放在应用程序的bin子目录里。
创建一个指向应用程序目录的IIS虚拟目录。
.aspx类的生成
ASP.NET应用程序是由IIS ISAPI过滤器aspnet_isapi.dll处理的。在第一次访问的时候，ISAPI过滤器在ASP命名空间下从Greeter.aspx生成一个.NET类然后把它编译成一个二进制库文件。IIS会自动搜索应用程序的bin子目录来寻找GreeterLogic基类。图D显示了生成的类的继承关系。生成的二进制文件会放在一个根据应用程序的虚拟目录而生成的一个存放临时ASP.NET文件的目录里。例如，如果Greeter的虚拟目录被命名被IntroASPNET，那么Greeter.aspx可能会生成一个名字为effla-hh.dll的二进制文件，并且放在诸如C:\WINNT\Microsoft.NET\Framework\v1.0.3328\Temporary ASP.NET Files\introaspnet\b5d8b0af\51648ab7这样的一个目录里。
如果Greeter.aspx被修改了，那么ISAPI过滤器会在下一次页面访问的时候自动重新生成二进制文件。
ASP.NET是实打实面向对象的
那么所有这些意味着什么呢？ASP.NET提供了一个真正的面向对象的编程模型。WebForms能够让页面的UI完全独立于页面的逻辑而被创建然后通过继承而结合起来。不会再有夹杂着HTML和VBScript的页面了。页面的逻辑是使用一种全功能的.NET语言，比方C#, Visual Basic.NET, 或者 Jscript.NET实现的。更进一步的说，页面逻辑的实现过程可以随意使用所有的.NET基类类库。Web服务器控件封装了不同Web浏览器之间的区别并允许你从更高的级别来设计Web页面。所有的一切都会被编译成微软中间语言（MSIL）并且能够在运行时同步转化成机器码。不会再有解释性页面中存在的那种性能损失了。如果这还不能叫做一种革命的话，我就真的需要一本新的字典了:-)。
<html>
<head>
<title>Greeter.aspx</title>
</head>
<body>
<form id="QueryName" method="post" runat="server">
<!-- Heading -->
<asp:Label id="m_Heading" runat="server" Font-Bold="true" Font-Size="16pt" Text="Please enter your name:">
</asp:Label>
<br>
<!-- Input controls -->
<asp:Label id="m_Label" runat="server" Font-Bold="True" Text="Name:">
</asp:Label>
<asp:TextBox id="m_TextBox" runat="server" Width="152px"></asp:TextBox>
<asp:Button id="m_Button" runat="server" Text="Get Greeting"></asp:Button>
<br><!-- Input validation -->
<asp:RequiredFieldValidator id="m_Validator" runat="server" ControlToValidate="m_TextBox" ErrorMessage="You haven't entered your name!" ForeColor="Red">
</asp:RequiredFieldValidator>
</form>
</body>
</html>
using System;namespace TechRepublic
{
public class GreeterLogic : System.Web.UI.Page
{ // Protected data members: // - Server controls created by the .aspx derived class.
protected System.Web.UI.WebControls.Label m_Heading;
protected System.Web.UI.WebControls.Label m_Label;
protected System.Web.UI.WebControls.TextBox m_TextBox;
protected System.Web.UI.WebControls.Button m_Button;
protected System.Web.UI.WebControls.RequiredFieldValidator m_Validator; // Initialize the page.
override protected void OnInit( EventArgs e )
{ // Attach an event handler for the GetGreeting button click.
this.m_Button.Click += new System.EventHandler( this.m_Button_Click ); // Initialize the base class.
base.OnInit( e );
} // Handle the "Get Greeting" button click.
private void m_Button_Click( object sender, System.EventArgs e )
{ // Set the greeting in the heading.
m_Heading.Text = "Greetings " + m_TextBox.Text + "!"; // Hide the label, text box and button.
m_Label.Visible = false;
m_TextBox.Visible = false;
m_Button.Visible = false;
}
}
}
2005-11-26 09:19
由于我同时是ASP和JSP的程序员，所以正开始写一系列的文章来比较两者的差别，当我写到一半时，ASP+被宣布了，所以我不得不重新开始审视这个问题。我正在同时做一个JSP项目和一个ASP项目，后者十分有趣，因为它开始是采用ASP3.0，但当项目结束后我将会转换为ASP+。到那时我将可以对ASP+有更近的考察，并提供更好的ASP+和JSP的比较。本文是我目前对ASP+的一些认识和看法，并分析了它对于象我这样的普通开发人员可能会产生的影响。
通过最初步的比较，我发现：
1) 面向对象性:
ASP+将C#作为一种面向对象语言，在很多方面来看，C#将成为微软的与Java相似的语言。
C#另一个有趣的地方是所有对象都自动变成为COM对象。如果C#能取得很大的市场份额，那么它将给ASP+带来类似于Java的功能，并且具备更快的性能，因为它可以和Windows环境紧密集成。
C#是ASP+开发中一个最重要的功能，微软会将C#发展成为Java的强劲对手。这也是微软.Net框架的一个重要组成部分。我认为C#是微软在编程市场上击败对手的主要工具。我期待着微软能在这个产品后面倾注全力，这样，C#可以成为许多程序员的又一种选择。C#的诞生无疑将进一步加剧微软和Sun产品的战线，但这对用户是有利的，他们可以选择两者之一来开发新的应用。
2) 数据库连接：
ASP另一个亮点是它使用ADO对象、ODBC、OLE-DB和事务处理管理器。因此ASP Web数据库应用开发特别简单。ASP+发展了更多的功能，因为有了ADO+！ADO+带来了更强大更快速的功能。JSP和JDBC目前在易用性和性能上同ASP/ADO相比已有些落后，当新版本ASP+/ADO+出现后这样的差别会更明显。所以我个人希望SUN应尽快能花大力气来追赶ASP+/ADO+的组合。
3)大型站点应用：
ASP+将对大型站点(web farms)有更好的支持。事实上，微软已经在这方面付出了巨大的努力。 ASP+可以让你考虑到多服务器(multiple servers)的场合，当你需要更强大的功能时，仅仅只需要增加一台服务器。整个.Net框架已经充分地提供了这个方法。ASP+提供了外部会话状态(external session state)来提供内置式web farm的支持。另外，由于请求的各组件相互间经过了充分的优化，所以速度很快。
于是ASP+现在可以在大型项目方面与JSP一样具有等同的能力。而ASP+还有价格方面的优势，因为所有的组件将是服务器操作系统的一部分。对于JSP,你需要购买昂贵的应用服务器群来达到同样的目的。
4) ASP+还提供更多的其它方面的新特性，例如：
*内置的对象缓存和页面结果缓存。
*内置的XML支持，可用于XML数据集的简单处理。
*服务器控制提供了更充分的交互式控制。
由此可见，ASP+确实对ASP进行了较大的发展。
在我审视完ASP+后，我的初步结论是：我未来项目主要还是要采用基于Java/JSP的技术。这有以下三个理由：
1) 要真正发挥ASP+潜力，你要使用C#或vb.net。这两种语言将成为ASP+标准的核心的脚本语言。这对ASP的未来发展很有好处。而我向来不喜欢用当前的Visual Basic来制作com对象。新的ASP+核心脚本语言更能发挥ASP+的价值。
显然，所有这些ASP+的新进展促使我对今后语言选择做一个决定，它将占据我未来的无数时间和努力。
回想起来，当Java开始发展起来时我正好学习了Java，那时我预感到这将是围绕我未来程序生涯的语言。于是，JSP理所当然地成为了我在web开发中的第一选择。
现在我已经是一个JSP fan，除非微软能够将我整个扭转过去，我感觉到自己正面临ASP+的巨大挑战。
2) ASP+依然完全锁定在微软的操作系统中。JSP比ASP+拥有更大的范围，它在别的服务器配置中也有很好的伸缩性。虽然Windows 2000 的优越性日益显露，但这对开发人员不构成问题。
3) 我并不能确信是否我能认同ASP+结构的各种方面，这需要更深入的分析，所以，我很犹豫。也许直到我使用了1-2个月后才会改变看法。总的来说，这需要在一个很高的层次来看待这个beta产品。
而作为一个ASP开发人员，ASP+也让我要停下来反思一下。未来8个月的ASP新项目将变得很困难。为什么？因为 ASP+和C# 带来了一个难题，它们要到2001年才正式提供。而很多性能方面的要求现在就需要确定。由于ASP+只是一个beta软件，所以现在我的第一个选择反而很简单了。现在的项目就采用ASP3.0。我认为各种beta版的语言都不太可信。
但我不能忽视ASP+,因为它很快就要推出，并代表了ASP的未来。ASP项目的管理者还需要考虑到未来的可平滑移植性及付出的时间代价等。另一个结果则是，这使得在近期使用PHP和JSP来代替ASP变得更可靠一些。
总的来说，
1) 如果使用ASP+，你将花费额外的时间学一些新的工具。
2) 新的工具有待于版本化，所以为什么不先关注于目前存在的东西？
3) ASP+将来会拥有的特性JSP已经拥有。
4) ASP+将你锁定到纯Microsoft的体系中。
最后，我预测会有很多人加入到PHP和JSP的行列。可是，仍然会有一部分人会受到ASP+给业界带来的激动所感染。我从没看到一个beta编程产品会带来如此的震撼！
同时，我还注意到一篇讨论.net的文章中也提到了同样的问题：
ASP+以自由软件作为开始，现在已经渐渐成为Microsoft的.Net框架的基石之一。Sun应该从中得到教训。特别注意的是，你需要许可证才能升级到ASP+，因为它和太多的产品集成在一起了。.Net框架太大了。在假定某个产品可以成为真正的产品之前，我通常等待它的第一个service pack。所以，即使ASP+已经在2001第一季度被版本化，我仍然要等到2001第二季度。
当然，因为ASP+ 已经产生了如此的激动人心，一旦推出，很多商店都会马上提供ASP+。
事实上我早已经使用beta版ASP+! 我发现它使用 .aspx 后缀，这使我我感觉Microsoft会在近期推出第一个ASP+的service pack。
下一年里，我们将看到在这个巨大的市场上Sun和Microsoft如何展开决战，而程序员们又将做出什么样的选择呢？
2005-11-26 09:19
2005-11-26 09:22
