博客大管家小废 物
ORM框架在删除数据方面一直有个尴尬，那就是无法通过指定条件批量删除数据。于是对于一些删除操作，我们不得不写SQL语句或者执行存储过程。幸运的是C# 3.0所拥有的强大特性足以让我们对LINQ to SQL的功能进行扩展。为了更好地进行项目开发，以及周五的一次技术交流，我为LINQ to SQL扩展了批量删除功能。
异步操作是提高Web应用程序吞吐量的重要手段，关于这方面的话题已经在前文《正确使用异步操作》中解释过了。对于大多数互联网应用来说，性能瓶颈数据库访问。换句话说，一个请求在数据库操作上所花的时间往往是最多的——并且占总时间的90%以上。因此，当Web应用程序的吞吐量因为数据库操作的阻塞而受到影响的话，我们可是尝试使用异步数据库操作来进行优化。那么我们又该如何使用LINQ to SQL进行异步查询呢？
本想写一点有关LINQ to SQL异步调用的话题，但是在这之前我想还是先写一篇文章来阐述一下使用异步操作的一些原则，避免有些朋友误用导致程序性能反而降低。这篇文章会讨论一下在.NET中有关异步操作话题，从理论出发结合实际，以澄清概念及避免误用为目标，并且最后提出常见的异步操作场景和使用案例。这样我们就可以知道什么时候该使用异步操作，什么时候会得不偿失。
目前LINQ to SQL的资料不多——老赵的意思是，目前能找到的资料都难以摆脱“官方用法”的“阴影”。LINQ to SQL最权威的资料自然是MSDN，但是MSDN中的文档说明和实例总是显得“大开大阖”，依旧有清晰的“官方”烙印——这简直是一定的。不过从按照过往的经验，在某些时候如果不按照微软划定的道道来走，可能就会发现别样的风景。老赵在最近的项目中使用了LINQ to SQL作为数据层的基础，在LINQ to SQL开发方面积累了一定经验，也总结出了一些官方文档上并未提及的有用做法，特此和大家分享。
ScottGu同学最近在Blog上发布了一些有关MIX 2008和ASP.NET MVC框架的消息。
在Web程序中上传文件是很常见的需求，最近忽然想到了点这方面的内容，就随便谈谈吧，希望对大家有帮助。
[url]http://www.51cto.com/exp/hhhchina/heroes/index.html[/url] 老赵今天早上大约9点开始被人刷票，当时票数为8700多，但是不久后就发现票数就到达了近万。在发现刷票情况后（当时大约9点半）老赵立即联系了51cto的编辑和主办方（微软）的人，他们均表示会立即汇报，可惜已经无法制止票数上涨。票数依旧以每秒2-3票的速度持续增长，直至中
微软近期发布了一个MSDN Code Gallery站点，从名字上就可以看出，这是一个用于存放代码的“展馆”。 MSDN Code Gallery和CodePlex的区别在于，前者用于存放各种大大小小的资源，而后者则是一个项目管理平台。不过虽然MSDN Code Gallery的内容比较“零碎”，但是功能似乎还是不少的，甚至可能上传视频说明。希望这个能够成为GotDotNet后新一代微软
明日博客园上海俱乐部活动，老赵有幸受邀与大家一起讨论一下ASP.NET方面的问题。经过了一段时间的思考，我准备这次的主题定为“ASP.NET WebForms、MVC与MVP的演变与结合”。 前一段时间在博客园（甚至整个.NET社区）的焦点都定在了新发布的ASP.NET MVC框架上，由此也引发了ASP.NET WebForms和ASP.NET MVC之间孰优孰劣的讨论。老赵当时为Web
.NET 3.5中增强了WCF的功能，为它提供了发布RESTful服务和Syndication（即常见的RSS或Atom）的能力。现在我们开发RESTful的服务或API就非常简单了。同样，无论是分析还是发布RSS也都有了现成的类库（开源产品中原本也有RSS.NET和Atom.NET，不过好像现在都商业化了？）。 MSDN上这方面资源很多，看完类库参考和示例代码（其实并不很多）一般已经足
在之前的文章里我们已经谈论了有关URL Rewrite的几个主要的方面。在本系列的最后一篇文章中，我们就来讨论一下有关不同级别URL Rewrite的一些细节与特点。 理论上说，IIS级别的URL Rewrite使用C或C++编写，比使用托管代码编写的ASP.NET级别URL Rewrite性能要高。但是我认为这方面的差距在大部分情况下可以忽略不计，这种性能几乎不可能成为性能瓶颈。因此选择何
在进行了URL Rewrite之后，经常会遇到的问题就是页面中PostBack的目标地址并非客户端请求的地址，而是URL Rewrite之后的地址。以上一篇文章中的重写为例： namespace Sample.Web.UI.Adapters{ public class FormRewriterControlAdapter :
可能已经没有人会使用上一篇文章中的方法进行URL Rewrite了，因为提供URL Rewrite的组件早已铺天盖地了。 ASP.NET级别的URL Rewrite组件的原理很简单，其实只是监听BeginRequest事件，并且根据配置来决定目标URL。在我之前接触过的项目中，发现使用URLRewriter作为URL Rewrite组件的频率非常高，我想可能是因为那是微软提供的东西吧。
之前觉得这个话题已经被谈滥了。URL Rewrite早已经被广大开发人员所接受，网上关于URL Rewrite的组件和文章也层出不穷，但是总是让我感觉意犹未尽，于是最终还是忍不住提笔写了这系列文章。这些文章不会谈论URL Rewrite的价值与意义，而只会谈论纯技术的内容。文章中也不会有详尽地实现分析，而是结合了我的经验，从应用角度来讲解这个话题。您已经知道的，您还不知道的，别处已经讲过的，或者还
User Control大家肯定不会陌生，在使用ASP.NET的过程中，除了aspx页面，最常见的就莫过于ascx了。ascx是一个有独立逻辑的组件，提供了强大的复用特性，合理使用，能够大大提高开发效率。通过User Control直接生成HTML内容其实已经是一个比较常用的技巧了（尤其在AJAX时代），不过网络上这方面的内容比较少，很多人还是在苦苦地拼接字符串，因此在这里我通过一个实例简单介绍一
四、生成复杂的ID难以使用JavaScript操作 我在上一篇文章的最后提到了，虽然使用WebForms我们能够对于页面上的HTML属性和样式等进行自由的定制和控制，但是有一点是毋庸置疑的，我们没有办法（正常的办法吧，Hack不算）让服务器端控件在客户端生成一个简单的ID。例如，一个TextBox控件，在服务器端的ID是txtUserName，但是最终在客户端生成的ID可能是LoginFor
没想到我的文章引起了那么大的反应，看来最近MVC框架的确是一个热门话题。正如上一篇文章开始所说的，我不会对MVC框架有任何“贬低”，任何技术滥用都有问题，所以任何东西都会有所谓的Best Practice（去MSDN的Patterns & Practice栏目看看就知道了）。我写这几篇文章，是想说明，很多WebForms的缺点是被夸大了。WebForms的确有缺点，但是我们完全可以避开，并
记得数年前，当ASP.NET刚出现时，天下间Web开发框架中似乎出现了一个“巨人”，WebForms这种似乎人人都能掌握的开发框架几乎瞬间流行起来。如果谁还在用传统ASP这种控制与表现混合的开发方式，似乎立即变得低俗了许多。于是乎许许多多人都学会了拖控件+绑定的方式，“Web开发人员”也越来越多，一片红火，好不热闹。 风水轮流转，不知从什么时候开始Rails框架随着RoR忽的流行了开来，.N
在《在Linq to Sql中管理并发更新时的冲突（2）：引发更新冲突》一文中，我们描述了Linq to Sql检测在更新时是否产生了冲突的基本方法：将该记录每个字段原来的值和更新时的值进行对比，如果稍有不同则意味着记录被修改过，因此产生了更新冲突。不过您是否有这样的感觉，这种方法实在累赘了一些？如果一个表中有数十个字段，那么更新就必须完整地检测一遍（不过我会在今后的文章中提到这方面的控制）。再者
查询计划 Sql Server在执行一条查询语句之前都对对它进行“编译”并生成“查询计划”，查询计划告诉Sql Server的查询引擎应该用什么方式进行工作。Sql Server会根据当前它可以收集到的各种信息（例如内存大小，索引的统计等等）把一条查询语句编译成它认为“最优”的查询计划。很显然，得到这样一个查询计划需要消耗CPU资源，而大部分的查询语句每次经过编译所得到的查询计划往往是相同的
Live Messenger对话框 时常在某些朋友的blog中看到一个可供聊天的对话框，它能让正在浏览这个站点的用户进行聊天。不过在我看来，这个功能形同鸡肋——谁会知道哪些人正在浏览，又有哪些人可以聊天呢？不过今天在浏览LoveCherry的blog时发现在左侧边栏里出现了一个可供聊天的Live Messenger对话框，顿时让我产生了兴趣。不过知道这个东东的人似乎还不多，因此只能动用搜索引
无论与目前的ORM框架相比有没有优势，Linq to Sql在语言和平台的级别上为我们提供了一种新的操作对象和数据的方式，在一定程度上为我们解决了Object != Data的问题。在实际应用中，对于数据库的操作往往有着天生的并发性，因此在更新数据时可能会产生冲突。有些时候，如果没有合理的解决冲突问题，轻则让用户摸不着头脑，重则让系统数据处于一种不一致的状态。Linq to Sql自然考虑到了这一
看了不要迷失在技术的海洋中，深表同意。在后来的评论中大家也表达了自己的看法。让我觉得很有意思的是，大家的观点惊人地一致——几乎没有反对的声音。 不过从经验上来看，意见太统一也不一定是一件好事。我有时也会小人之心地想，表示赞同的朋友们是真与LoveCherry的想法一致，还是仅仅因为自己以前对待技术随波逐流不堪所累，现在把这篇文章作为救命稻草看待，追求自身的心理平衡呢？LoveCherry写这
前言 对于一个应用程序来说，最重要的特性之一就是安全性。例如，安全方面的需求往往会最早被提出，安全方面Bug的优先级和危害程度往往都被定为最高。有时候为了提高安全性，还需要牺牲一定的性能或者其他因素。因为性能，往往可以通过一些别的方式，例如添加一台服务器作负载均衡来解决（顺便插一句，我现在觉得对于企业来说，能够用钱解决的往往就不是问题了），或者在之后的版本中进行优化；但是如果出了安全性方
之前遇到一个要求，需要能够取消一个正在进行中的Web Service。这也是我第一次遇到这个功能，不过不难，我想。既然ASP.NET AJAX的客户端与服务器端通信完全通过Microsoft AJAX Library的异步通信层进行，那么我们只要得到正在请求Web Service的Sys.Net.WebRequest对象，调用其abort方法就可以了。但是究竟应该如何得到这个对象呢？于是我粗略地阅
背景 在我看来，toString方法是一个类最重要的方法之一。在JavaScript中，将一个对象转化为字符串形式的默认方法就是调用其toString方法。因此，为类型实现一个合理的toString方法对于开发和调试都有一定的好处。在面向对象编程中，在父类中定义toString方法，以此为它的各个子类提供相似的字符串表现形式是常用的做法之一，但是如果您使用Microsoft AJAX L
背景 在《分清ASP.NET AJAX中的Extender和Behavior模型》一文中，我谈到了使用AjaxControlTookit中控件的关键是客户端的各Behavior组件。微软官方推出的示例都太过于重视演示效果，而忽略了实际使用中的问题——市场需要吧，要让技术看上去吸引人，这么做无可厚非。但是作为一个实际开发产品的程序员，如果要灵活地使用AjaxControlTookit中的组
背景 缓存是开发高性能和高可用性Web应用的重要手段之一。作为ASP.NET AJAX的关键功能，从客户端访问Script Method会被大量用于使用ASP.NET开发的AJAX应用。以下是这一功能最简单的例子。 <asp:ScriptManager ID="ScriptManager1" runat="server" ScriptMode="Debug"> <
背景 ExtenderControlBase类是开发AjaxControlTookit服务器端Extender组件的基础。ExtenderControlBase基于ASP.NET AJAX的Exnteder模型提供了许多方便开发人员的强大支持，能够在它的基础上开发Extender确实是一件非常容易的事情，这样我们就可以将更多的精力放在客户端Behavior的逻辑上了，那才是AjaxContr
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
