Sun, 23 Dec 2007 18:27:00 GMT博客园同步更新http://blog.csdn.net/hjf1223/http://blog.csdn.net/hjf1223/archive/2007/12/23/1963122.aspxhttp://blog.csdn.net/hjf1223/comments/1963122.aspx0http://blog.csdn.net/hjf1223/comments/commentRss/1963122.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1963122关于ViewState我曾经有过几篇博客的讨论《客观看待ViewState对Asp.net程序作用和影响》，《"Validation of ViewState Mac failed" exception》《回发事件执行很慢的问题.》。时过今日，我想从我目前的经验来总结，我们该如何来控制ViewState才是比较合理的。 ViewState是ASP.NET的一个独创设计。它为用户在进行Web开发时带来了极大的便利，特别是对于一个WEB开发新手来说，它完全可以不用自己去维护WEB控件的状态，在进行事件驱动开发时，用户只管通过控件ID来获取当前控件的值，而其它的细节ASP.NET都是对用户透明的，所以非常易于入门。而它所带的负面影响也是明显，有时候也是而严重的，最严重的就如上的那篇回发事件执行很慢，甚至时常出现“Validation of viewstate MAC failed”你也不会感到意外。 那么我们该如何来控制和使用ViewState呢？我想最好还是禁用它，但是也不绝对是这样的。你可以根据你的应用来决定是否禁用ViewState，那么决定因素有哪些呢？ 1)你的生产环境，也就是说你<img src ="http://blog.csdn.net/hjf1223/aggbug/1963122.aspx" width = "1" height = "1" />Mon, 24 Dec 2007 02:27:00 +0800阿不http://blog.csdn.net/hjf1223/archive/2007/12/23/1963122.aspx#Feedbackhttp://blog.csdn.net/hjf1223/archive/2007/12/23/1963122.aspx阿不http://blog.csdn.net/hjf1223/archive/2007/12/23/1962376.aspxhttp://blog.csdn.net/hjf1223/comments/1962376.aspx0http://blog.csdn.net/hjf1223/comments/commentRss/1962376.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1962376首先声明，这不是真的就是什么Best Practice。只是看了老赵的文章里面提到了WebForm的Best Practice这个词汇后，突然有了这样的想法，把自己平常在使用WebForm开发过程当中，自己认为比较好的开发实践拿出来与大家共享，这个可能不是我一个人能完成，希望大家都能参与进来。由于平常我写博客并没有太多的耐心和持续性，三分钟热度要过了就不了了之了，所以虽然现在比较晚了（刚过0点），但为了这篇博客能够最终成型，还是决定连夜把这篇博客赶出来。 近一段时间以来，我发现博客又掀起了新的一轮讨论热潮，特别是针对WebForm和MVC的讨论。这样的讨论可以促进大家的进步，同时也可以让每个人对每种技术的了解都更加深入。不同的技术都有自己的最佳实践，比如WebForm和MVC。如果我们大家在平常的开发实践中都能遵从每一种技术基本使用原则，而不是滥用，那么我就不信不会得到最佳效果。 这里，我要讨论的是如何合理的利用DataSourceControl，来简化我们在页面的一些数据操作，代替一部分的参数处理工作，并最终取代页面的后台代码文件。这个思路，源于在asp.net Blogs的一篇文章<img src ="http://blog.csdn.net/hjf1223/aggbug/1962376.aspx" width = "1" height = "1" />Sun, 23 Dec 2007 23:32:00 +0800阿不http://blog.csdn.net/hjf1223/archive/2007/12/23/1962376.aspx#Feedbackhttp://blog.csdn.net/hjf1223/archive/2007/12/23/1962376.aspx阿不http://blog.csdn.net/hjf1223/archive/2007/12/20/1955656.aspxhttp://blog.csdn.net/hjf1223/comments/1955656.aspx0http://blog.csdn.net/hjf1223/comments/commentRss/1955656.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1955656关于JAVA与.NET的争论从来就没有停止过。相信标题就足于吸引许多人的目光，但我无意在博客园里从新挑起一翻新的争论。但是今天与一位比较有资历的同事探讨起了关于.NET与JAVA的话题，同时自己也在JAVA开源方面有一些需求，因此就有了这方面的思考。 事情过程大概是这样的，同事希望我们逐步转向JAVA路线，利用JAVA来实现SOA架构的产品。然后他认为微软在SOA方面还没有实质的产品，或者说支持力度还不够。或许他本身并不是技术人员，但又专注于架构方面。让他对当前流行的各种最前卫的架构概念比较迷念，说起架构条理清楚，但是从中你却又明显的感觉到缺少一些简单的技术常识。不过，在与之交流过程中，做为一名纯粹技术人员的我，却又收益不少。 首先，我对技术分派是中立的。我使用.NET，并不会对JAVA有任何的敌意。大数人使用哪种技术都与自己的性格，和首次接触有关。特别是初次接触的技术，就如初恋一样，会有种特殊的怀情结在里面，我就是其中之一。当你在这样的一条道路越走越远，双方的认识越来深的时候，越发的难于放手。但是，除了你的初恋女友外，你能不能对其它的女孩充满敌意呢？不能！人家漂亮，你还得夸人家漂亮。<img src ="http://blog.csdn.net/hjf1223/aggbug/1955656.aspx" width = "1" height = "1" />Thu, 20 Dec 2007 22:13:00 +0800阿不http://blog.csdn.net/hjf1223/archive/2007/12/20/1955656.aspx#Feedbackhttp://blog.csdn.net/hjf1223/archive/2007/12/20/1955656.aspx阿不http://blog.csdn.net/hjf1223/archive/2007/12/18/1947385.aspxhttp://blog.csdn.net/hjf1223/comments/1947385.aspx0http://blog.csdn.net/hjf1223/comments/commentRss/1947385.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1947385不断有朋友希望能提供一些示例，同时我也发现，单纯发一些文字性的教程。大家好像都没有看明白NBear.Mapping是干嘛用的，所以从这篇开始我会陆续以实例的方式介绍NBear.Mapping的使用，以便给大家直观的印象。这篇我们首先关注的是对象与对象间映射，在这篇文章里你将会看到。即使你的项目不需要与数据库的映射，NBear.Mapping在日常开发中也会给你带来非常大的帮助。 就如之前教程介绍的那样，有一个IUser接口，这个接口定义了用户的一些基本属性： 1: public enum UserStatus 2: { 3: Normal, 4: Admin 5: } 6: public interface IUser 7: { 8: int? ID { get;set;} 9: string Name { get;set;} 10: string Address { get;set;} 11: int Age { get;set;} 12: UserStatus Status { g<img src ="http://blog.csdn.net/hjf1223/aggbug/1947385.aspx" width = "1" height = "1" />Wed, 19 Dec 2007 03:34:00 +0800阿不http://blog.csdn.net/hjf1223/archive/2007/12/18/1947385.aspx#Feedbackhttp://blog.csdn.net/hjf1223/archive/2007/12/18/1947385.aspx阿不http://blog.csdn.net/hjf1223/archive/2007/12/18/1947381.aspxhttp://blog.csdn.net/hjf1223/comments/1947381.aspx0http://blog.csdn.net/hjf1223/comments/commentRss/1947381.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1947381在你的项目中，如果不使用ADO.NET对象，那么都要做一件事，就是要把查询的DataTable或IDataReader对象转换成实体对象，或者叫映射。比如ORM工具，它帮我们做好了所有事情，iBatis它帮我们完成了执行SQL和实体映射的工具。还有一些是使用Attribute + 反射的方式来实现。现在你又多了一种选择，你完全可以使用NBear.Mapping来帮你完成这个工作。这里的例子仍然使用上篇中定义的User类。 实体对象转DataRow 在有的情况下，你可能会希望把一个对象转换成DataRow，那么你这时可能会去定义与对象对应的DataTable的Schema，然后再用这个DataTable.NewRow()来创建一个DataRow对象，再将属性一个一个的进行赋值，会需要很多繁琐的步骤。这时候如果使用NBear.Mapping，情况会变成什么样呢？让我们来看看吧：DataRow outputObject = ObjectConvertor.ToObject&lt;DataRow&gt;(user); 正如你所看到的，就一句代码就可以完成所有的工作。需要注意的是这时输出的Da<img src ="http://blog.csdn.net/hjf1223/aggbug/1947381.aspx" width = "1" height = "1" />Wed, 19 Dec 2007 03:33:00 +0800阿不http://blog.csdn.net/hjf1223/archive/2007/12/18/1947381.aspx#Feedbackhttp://blog.csdn.net/hjf1223/archive/2007/12/18/1947381.aspx阿不http://blog.csdn.net/hjf1223/archive/2007/12/16/1942616.aspxhttp://blog.csdn.net/hjf1223/comments/1942616.aspx0http://blog.csdn.net/hjf1223/comments/commentRss/1942616.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1942616在NBear.Mapping中提供了一种灵活的配置方式，允许你在不改变原有代码的情况，随时对映射需求进行修改，同时即使你在开发初始期不进行配置，它仍然可以正常的工作。极大的方便你的开发和维护工作。 在你使用ObjectConvertor的接口进行对象映射时，系统会根据你指定的输入类型（如果没有指定则以inputObject的类型为准）、输出类型和viewName，去查找系统已经存在的对应的配置（表现为一个缓存的ObjectMapper对象），如果找到这个配置，则会使用这个ObjectMapper对象，否则会新创建一个ObjectMapper对象来执行映射动作。 在NBear.Mapping.Test中，你可以找到NBear.Mapping.config最完整的配置语法案例，它主要有以一些配置节点： 1: &lt;NBear.Mapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"&gt; 2: &lt;typeAli<img src ="http://blog.csdn.net/hjf1223/aggbug/1942616.aspx" width = "1" height = "1" />Mon, 17 Dec 2007 06:14:00 +0800阿不http://blog.csdn.net/hjf1223/archive/2007/12/16/1942616.aspx#Feedbackhttp://blog.csdn.net/hjf1223/archive/2007/12/16/1942616.aspx阿不http://blog.csdn.net/hjf1223/archive/2007/12/16/1942405.aspxhttp://blog.csdn.net/hjf1223/comments/1942405.aspx0http://blog.csdn.net/hjf1223/comments/commentRss/1942405.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1942405在新版本的NBearMapping中，你不需要手工去实例化ObjectMapper 对象。取而代之的是ObjectConvertor类，在这个类中提供了多种的重载方法，来方便你使用。主要的方法重载有：ToObject；ToList；ToDataTable。 ToObject 1: public static OutputType ToObject&lt;OutputType&gt;(object inputObject) 2: public static OutputType ToObject&lt;InputType, OutputType&gt;(InputType inputObject) 3: public static OutputType ToObject&lt;InputType, OutputType, InitType&gt;(InputType inputObject) 4: public static OutputType ToObject&lt;InputType, OutputType, InitType&gt;(InputType inp<img src ="http://blog.csdn.net/hjf1223/aggbug/1942405.aspx" width = "1" height = "1" />Mon, 17 Dec 2007 04:07:00 +0800阿不http://blog.csdn.net/hjf1223/archive/2007/12/16/1942405.aspx#Feedbackhttp://blog.csdn.net/hjf1223/archive/2007/12/16/1942405.aspx阿不http://blog.csdn.net/hjf1223/archive/2007/12/15/1940245.aspxhttp://blog.csdn.net/hjf1223/comments/1940245.aspx0http://blog.csdn.net/hjf1223/comments/commentRss/1940245.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1940245在Teddy 的博客《NBearMapping - 开源通用对象映射组件v1.0.0.2 beta - 支持枚举类型字段》，介绍了NBear 的一些功能。由于这将是NBearV4中的一个基础组件，所以对性能的要求比较严格。原先的性能相对还是比较难以满足要求，在此基础框架思路下，经过近一段时间的开发，终于完成了NBearMapping新版本的开发，这个版本的主要功能仍然不变，在此基础上新增了： 1、对配置语法的支持。 2、简化了使用接口。 3、重新设计了映射实现，支持不同字段类型的自动转换，同时具备了非常高的性能。性能与手工代码相比不会有大的损失，在相同字段类型映射时，性能与手工代码相当（有时的从测试效果来看还会更好些）。在不同字段类型映射，NBearMapping 与手工代码的时间比大约在 1.3(到2.0）比1之间。可参考MappingTest.TestPerformance 1-4测试用例。 NBear.Mapping是一个独立组件，不会依赖于NBearV4的其它组件。因此它是可以单独使用的，甚至你也可以与NBearV3同时使用。目前新版本支持： 1、对象与对象之间，对象与弱类型之<img src ="http://blog.csdn.net/hjf1223/aggbug/1940245.aspx" width = "1" height = "1" />Sun, 16 Dec 2007 04:12:00 +0800阿不http://blog.csdn.net/hjf1223/archive/2007/12/15/1940245.aspx#Feedbackhttp://blog.csdn.net/hjf1223/archive/2007/12/15/1940245.aspx阿不http://blog.csdn.net/hjf1223/archive/2007/12/15/1939973.aspxhttp://blog.csdn.net/hjf1223/comments/1939973.aspx4http://blog.csdn.net/hjf1223/comments/commentRss/1939973.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1939973年关将进，也看到了园子里的一些朋友对自己的2007进行了一些总结和回顾，不谈技术，也谈技术，引起大家广泛的关注。我的这个2007不期望能引起多大的关注，但是也希望能对自己即将过去的2007所做，所学，所想和所取得的进步与不足进行简单的总结。做为一种思考，也是为明年的发展方面进行一些初步的规划。也是希望能起到立贴为据，待到明年这个时候来回过头来看这篇总结的时候，感觉自己进步，这就够了。 从博客开始，可以说我的技术之路是与博客园一起慢慢成长起来的。我刚入行那会儿（05初），主要学习的资料就是从博客园得到的。那时候并不知道很多的外国技术资料，而国内也没有很比较好的.NET社区资源。那会儿博客园和MSDN中文网几乎是我所有的技术知识来源。今年以前，所写的技术博客也基本上都是自己遇到问题，解决问题的思路和过程。每解决一个问题自己都非常的兴奋，也都会写一篇博客来纪念一下。正因为有了这种习惯，让自己慢慢积累很多的解决各种问题的经验，也明显的看到了自己的进步。进入2007年以来，发现自己所写的博客少了，特别是上半年，尽管有，也是几篇没有什么技术含量的流水帐。一方面是工作的原因，这两个月前的10个月，工<img src ="http://blog.csdn.net/hjf1223/aggbug/1939973.aspx" width = "1" height = "1" />Sat, 15 Dec 2007 20:45:00 +0800阿不http://blog.csdn.net/hjf1223/archive/2007/12/15/1939973.aspx#Feedbackhttp://blog.csdn.net/hjf1223/archive/2007/12/15/1939973.aspx阿不http://blog.csdn.net/hjf1223/archive/2007/11/27/1904649.aspxhttp://blog.csdn.net/hjf1223/comments/1904649.aspx0http://blog.csdn.net/hjf1223/comments/commentRss/1904649.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1904649在asp.net ajax中，使客户端调用WebService变得非常的简单，而且非常有用（个人觉得这个功能是asp.net ajax的核心，很多与客户端的交互都需要这个功能来辅助实现）。那在EXT中，标准的客户端与服务器端交互，使用的是自定义的HttpHandler，而且服务器在处理客户端提交的参数也都必须是弱类型的使用方式，也会使用带一定的不便。如果你曾经使用过Asp.net ajax调用WebService，那你肯定非常希望EXT也能像那样简单的调用WebService。 默认情况下，EXT也是可以调用WebService的，在这篇博客里已经有做介绍《ExtJS与.NET结合开发实例(Grid之批量删除篇)》。但是在调用时传入多个参数和输出JSON字符串时，就需要使用asp.net ajax WebService的方式来调用了。 能被asp.net ajax调用的WebService必须被标上System.Web.Script.Services.ScriptServiceAttribute。根据我们的需要，我们还可以对每个WebService Method指定的它输出的序列化方式<img src ="http://blog.csdn.net/hjf1223/aggbug/1904649.aspx" width = "1" height = "1" />Wed, 28 Nov 2007 03:43:00 +0800阿不http://blog.csdn.net/hjf1223/archive/2007/11/27/1904649.aspx#Feedbackhttp://blog.csdn.net/hjf1223/archive/2007/11/27/1904649.aspx阿不