有关ASP.NET代码分离的一些讨论

　　关于ASP.NET代码分离（code-behind）的讨论的由来：

　　Visual Studio .NET（VS.NET）为Visual Basic的开发人员提供了一个非常直观的Web开发环境  。VB的开发人员已经有很多年都习惯于把他们的可视化接口拖放到设计接口上，然后在需要编写代码控制某个元素的时候双击这个元素  。我认为，VS.NET的最高成就在于：它已经采纳了Windows的软件设计和信息回圈模型（message loop paradigm），并把它们映射到了像Web这样的无状态环境里  。一旦你开始编写需要交付使用的应用程序，你就会发现这个映射并不完美，但是VS.NET能够把Windows的程序员迅速带入到Web开发的能力绝对是值得肯定的  。

　　当然有很多Web程序员会使用Visual Interdev、Visual Notepad或者其他Web开发的工具编写动态服务器页面（Active Server Page）  。这些程序员中的许多人在变动到VS.NET世界的时候有过一段艰难的时期  。他们原来习惯于将其应用程序分割成一系列ASP的页面，这些页面会同时封装可视化接口以及这个接口的行为  。

　　如果你看一下许多.NET还在beta版时期由ASP开发人员使用Framework SDK（在VS.NET正式上市以前）编写的代码示例，你能够看到的主要是行内（inline）代码示例  。这是因为他们还是按照ASP开发时的习惯编写代码  。事实上，开发人员能够最先得到的主要ASP.NET应用程序之一是iBuySpy Portal和Store  。这些应用程序在发表的时候就是以代码分离的形式呈现给VB.NET和C#开发人员的，并且还是的单页ASP.NET实现  。很多还是偏好单个文件ASP.NET应用程序的开发人员把iBuySpy的作为继续编写行内代码的过渡  。

　　ASP.NET代码分离有什么好处？

　　使用ASP.NET进行开发的每个.NET开发机构一定会碰到一些问题：我们是把C#还是VB.NET作为我们的核心开发语言？我们是不是要把行内ASP.NET的开发进行标准化，或是我们要严格地强制使用代码分离的文件？第一个问题的答案最后要看原有开发人员的经验和习惯，因为使用熟悉的语言会把你培训和适应语言的费用降到最低  。但是，关于代码分离的争论还不是很明确  。尽管有一些参考资料坚持认为代码分离是开发ASP.NET应用程序的正确道路，但是我还没有在微软出版的资料上看到任何关于这一点的建议  。所以你该如何决定呢？

　　ASP.NET代码分离之关于结构的争论

　　从结构的角度来讲，代码分离的文件允许更加简洁的系统实现  。代码分离的文件允许开发人员把用户界面（UI）的显示从UI的处理分离出来  。ASPX文件里只允许存在的代码是专门用来服务显示的代码  。在代码分离的文件里重新使用代码比在带有行内代码的单个文件里要简单一些（尽管仍然不简单）  。把设计和开发功能分离开来也是有可能的，只需要允许设计人员使用ASPX的文件和编码器进行代码分离的开发就行了  。使用行内代码实现这一点要困难得多  。

　　ASP.NET代码分离之关于环境的争论

　　尽管VS.NET允许你使用行内代码创建应用程序，但是其使用代码分离文件将UI处理低层进行抽象化的模型却直观得多  。在你使用代码分离而不是编写行内代码的时候，其编译器还能够进行类型检查和允许完全的IntelliSense  。对行内代码有错误的应用程序进行也是可能的，而这在以前只会在最终代码被执行的时候才能进行  。当你编译这个应用程序的时候，放置在代码分离文件里含有错误的相同代码会被截获  。

　　ASP.NET代码分离之行内代码有没有其他的正确用途？

　　我已经在前面列出了两个关于使用代码分离文件的主要争论，我想在下面指出的是可能要使用逐行代码的两种情况，这样才公平  。

　　ASP.NET代码分离的相关谈论内容就向你介绍到这里，希望对你了解ASP.NET代码分离技术有所帮助  。