sql

DLINQ 对数据库的操作也算直观，而且也支持 ORM 方式，ORM 部分的 Object 的定义方式比较复杂，应该是为了对于 Update 提供完善的支持，从而只对修改过的字段进行 Update。不过在我看来，意义不大，一般而言，就算是一条记录全部 Updata 开销也不大，而且，可以使用继承的方式来拆分某些大字段（Text 之类），以使之不被 Update：

白皮书中还举例说明了其他的方式，比如 return this.Vehicls.Where(p => p is Car); 或者 return this.Vehicls.Select(p => p as Car).Where(p => p != null); 只支持单表继承体系的确是很初级，不过从Linq To Sql的功能上来看，它主要强调的是从编译以及语言层面上来支持数据查询和分析，而不是强大的ORM，如果想

一般而言，对查询表达式的计算会导致以某种顺序生成一系列值，该顺序是底层信息源的固有顺序。要使开发人员能够显式控制这些值的生成顺序，应定义标准查询操作符来控制该顺序。这些操作符中最基本的就是 OrderBy 操作符。

看到这里，通用的 LINQ 与传统方法的差距就已明了。虽然仅仅是管中窥豹式的简单测试，但各位若无必要，还是尽量使用原生于数组的功能。当然，各位看官欲知为何差距如此之大，且听下回分解。水平有限，若有错谬，敬请谅解并指出。

有了SQL Server 2005之后，我们使用分页查询比老版本容易多了。在本文中，我将主要用到的是NorthWind数据库，所以你也可以仿照编写我所列举的范例。

ASP.NET 2.0根据数据源控件所表示的数据的性质将其区分为表格式组件或分层式组件。图3 列出了在2004年3月发布的ASP.NET 2.0社区技术预览版中支持的表格式组件和分层式控件。让我们从您可能最常使用的数据源控件（SqlDataSource）开始，来详细考察一下数据源控件。

对于把codebehind的aspx文件编译成dll，其中把aspx文件转化成cs源文件的原理同上，也是先设置一个"代码陷阱"，然后把"完整的编译 源"进行适当整理，保存为cs源文件。区别是在编译成dll时的步骤：（为叙述方便，假设界面文件为ex3.aspx，codebehind文件为 ex3.aspx.cs，ex3.aspx的"完整编译源"保存为ex3_aspx.cs）

首先要感谢微软的开发小组，因为大家可以利用他们高超而创新的技术来在Ms SQL Server 2005存储过程任何支持语言的.Net中编写受控代码了。简单地说，可以调用SQL Server 存储过程中的.net类库中的任何函数了。

我只是提供我几个我认为有助于提高写高性能的ASP.net应用程序的技巧，本文提到的提高ASP.net性能的技巧只是一个起步，更多的信息请参考《Improving ASP.NET Performance》一书。只有通过自己的实践，你才能找到对你的项目最有帮助的技巧。然而，在你的开发旅程中，这些技巧可以起一些指导性的作用。在软件开发中，这些都不是绝对有用的，因为各

　通过GetBinaryFormatData方法可以转换数据集为二进制，在服务器端使用,转换数据集格式。发送，客户端接收，得到二进制格式数据，使用RetrieveDataSet方法，反序列化，得到数据集，进行客户端操作。通过这些简单的操作(序列化和反序列化，将数据压缩)，可以使数据集等体积庞大的对象在远程传递中的时间大大减少，并且可以减少网络中断等问题对

于Atlas程序，在某些情况下，我们需要在短时间内调用大量的Web Service，例如某个列表中用户快速的点击删除。这时网络带宽，稳定程度等等往往会造成较长时间的延迟。如果可以将这些调用包装成一个单一的请求，那么用户只需忍受一次网络延迟，即可得到处理的结果，也间接的提高了效率。似乎这并不是一个很容易实现的功能，但幸运的是，Atlas中内

在该代码中如果i<0则不会判断j是否大于0，因为如果i<0无论j是否大于0返回的结果都是false；同理如果执行以下语句if (i>0 || j>0) Console.WriteLine("OK");如果i>0则不会判断j是否大于0，因为如果i>0无论j是否大于0返回的结果都是true。 但是在VB.NET中的And、Or不是“短路”运算符，And和Or都要计算运算符两侧的结果，这样会有不必要的运算。

ViewState是asp.net中的一个特性，它用于把生成页面要用的一状态值保存在一个隐藏域中。当页面被回传到服务器时，服务器要解析，校验和应用ViewState中的数据以还原页面的控件树。ViewState是一个非常有用的特性，它能持久化客户端的状态而不用cookie或者服务器的内存。大部分的服务器控件都是用ViewState来持久化那些在页面中与用户交互的元

数据展现为表格，来代替服务器端 DataGrid 的绑定工作，大大减轻了服务器的压力。并且客户端通过 AJAX 从持久层获取数据，会提高用户的使用体验。 二、将页面从数据中彻底独立出来，以便利用缓存。 有的应用了 AJAX 的页面还是会读取初始数据，这样的话页面就不能缓存。这些页面一般比较复杂，会比普通页面占有更多的资源，如

4. 适当使用服务器控件 在控件标记中加runat=server会增加web服务器的负担.除非有必要处理控件的属性,在服务器处理控件的事件时候就不要为标记加此属性 5.在必要的时候使用ViewState viewstate包含的控件越多,服务器负担就愈大,利用viewstate还可能惹出麻烦，例如一个显示错误信息的label控件，我们希望不要在每一个页面上都

缓存可以使应用程序的性能得到很大的提高，因此在设计应用程序以及对应用程序进行性能测试时应该予以考虑。应用程序总会或多或少地受益于缓存，当然有些应用程序比其他应用程序更适合使用缓存。对ASP.NET提供的缓存选项的深刻理解是任何ASP.NET开发人员应该掌握的重要技巧。

当我们把asp.net Forums 1.0集成在CS中的时侯，发现提交一个新的帖子的时候会非常的慢。每次新增一个帖子的时侯，应用程序首先要检查这个帖子是不是重复提的，然后用“badword”过滤器来过滤，检查图片附加码，作帖子的索引，把它添加到合适的队列中，验证它的附件，最后，发邮件到它的订阅者邮件箱中。显然，这个工作量很大。

在典型的应用中，当处理一个Web应用程序时，这个Web程序由多个部分组成。通常有我们的主Web站点，一个或多个Web服务，或是一个图象处理程序。IIS6为我们提供了为多个应用程序建立程序池的机会。应用程序池允许我们使应用程序在各自的单独进程中运行。这么做的好处是将我们的应用程序的不同组成部分分开，使它们分别运行在自己的内存空间中。由于

我们再从用户的角度看另外两个问题，曾使用ASP应用程序的人会发现ASP.NET应用程序使用时刷新频率很高，一个小小的动作都要提交到服务端去处理。从软件设计的角度看，我们觉得很合理，因为没有耦合且逻辑可重用。可是“鱼与熊掌不可兼得”，我们还是应该采取折中的手法。回到我们的系统中来，我们发现多数页面在对于使用较频繁的“增-删-改”操作

最后我们不得不从后台处理来考虑。我们发现后台的服务类以及业务逻辑被频繁调用，所以我们使用Singleton模式将底层业务逻辑类和工具类进行了重构，发现性能大幅提升。虽然有人说Singleton的一个缺点便是每次都需要检查类是否创建，这会消耗资源。但是检查所消耗的资源总比创建要小得多吧，何况不会无止境的吞噬宝贵的内存。