Visual
Studio .NET(VS.NET)为VB程序员提供了一个非常直观的Web开发环境。VB程序员几年来已经习惯了VB的编程方式，使用拖放控件设计界面，然后当想写代码控制一个元素时只要双击它就可以。我认为VS.NET最成功的地方是它已经将Windows软件设计带出了消息循环机制，并将其转换到像Web一样的无状态环境。一旦你开始编写产品软件，你很快就会发现这个转换并不完美，但是VS.NET的将Windows程序员很快带入Web环境的能力却是无可厚非的。
当然有很多Web程序员使用Visual Interdev、Visual Notepad或者其它Web开发工具学习ASP。他们中很多人在转到VS.NET时都会遇到困难。他们习惯于将应用程序分成一系列的包括外观界面和界面动作的ASP页面。
如果你看过很多在VS.NET推出之前的.NET beta时代由ASP开发人员用Framework SDK编写的示例程序，你会注意到它们都是使用内嵌代码方式。那是因为他们习惯以ASP的方式编写程序。事实上用于学习ASP.NET的第一个主要程序是iBuySpy Portal和Store。这些例子有用VB.NET和C#编写的code-behind版本，也有单页面的ASP.NET实现。我接触过的很多喜欢使用单页面ASP.NET应用程序的开发人员指出iBugSpy的发布实现肯定了对内嵌代码的继续使用。
每个.NET开发小组在进行其ASP.NET开发时肯定会这遇到几个问题：核心开发语言选用C#还是VB.NET？是规定使用内嵌式ASP.NET还是强制使用code-behind文件？跟据开发人员的经验，第一个问题很容易解决，因为使用他们熟悉的语言可以最大限度地降低成本。而有关是否使用code-behind的问题在组织内却没有那么容易统一。虽然有些文献中坚持认为在ASP.NET应用程序开发中应该使用code-behind文件，但是我还没有见过有哪个公开发布的建议书或是微软的推荐。该怎么决定？
从系统架构的角度看，使用code-behind文件可以有一个较清晰的系统实现。Code-behind文件可以使开发人员将UI显示从UI处理中分离出来。ASPX文件中唯一应该有的代码是用来指定服务的代码（一般是脚本）。在code-behind文件中代码复用比使用内嵌代码的单文件出现的比较早（虽然不简单）。而且还有可能让设计者设计ASPX文件而让代码编写者进行code-behind开发，从而将设计和开发分离。这比使用内嵌代码完成项目困难得多。
虽然VS.NET允许使用内嵌代码创建应用程序，但是使用code-behind文件设计的吸引人的低层的UI处理直观得多。在使用code-behind文件时，编译器也进行类型检查，而且还允许完全IntelliSense；这些在内嵌代码中都是不能实现的。在内嵌代码方式中很可能代码中的错误在程序执行时才会被发现。在code-behind文件中包含相同错误的代码则在编译阶段就会被发现。
基于对code-behind文件的两个主要的争论，而我认为有两种情况下需要使用内嵌代码。
我建议我的客户使用code-behind的原因很简单：你应该坚持一条原则，那就是将UI层从UI逻辑或商业中分离出来。那些使用code-behind的人可以从编译时警告、类型检查以及较好的调试支持中获得好处，因为VS.NET设计出来就是用于code-behind开发的。使用内嵌代码进行ASP.NET开发将会带来很多ASP的缺点。
作为应用程序架构师，我们要知道选择编码标准并不是一件简单的事情，但是编码标准应该使现在的和以后的开发人员容易理解、调试以及扩展我们今天写的代码。在你真正进入ASP.NET开发之前一定要确保你的组织中已经不存在内嵌代码和code-behind之间的争论了。
