摘要： 这篇文章将简单的分析一下有关静态文件捆绑的ASP.NET组件System.Web.Optimization的运行原理及基本的缓存问题； 在我们的项目里面充斥着很多静态文件，为了追求模块化、插件化很多静态文件都被设计成模块的方式或者被分解，在需要的时候在通过组合的方式在UI层上使用；这就带来一个问题，文件多了会影响浏览器加载页面的速度，而且由于浏览器的并发限制，对于并行.... 阅读全文

摘要： 最近一段时间结束了一个小项目的开发，觉得有些好东西值得总结与分享，所以花点时间整理成文章； 大多数情况下我们都知道这些概念，面向接口编程是老生常谈的话题了，有几年编程经验的都知道怎么运用；单元测试其实在前几年不怎么被重视，然而最近逐渐的浮现在我们眼前，而且被提起的频率也大了很多了，包括重构、可测试性都慢慢的贴近我们，我们只有亲自动手去使用它才能领悟其精髓； 阅读全文

摘要： 本来这篇文章是“[置顶].NET领域驱动设计—实践(穿过迷雾走向光明)”一文的一部分但是由于时间关系，完整的示例并没有跟文章同步发布，说实话时间太紧，写示例的目的是想全面的且细致的阐述DDD的分析、设计各个环节的最佳实践；原本想将文章的示例做好后在发布，但是由于工作关系和一些私人原因可能有一段时间不更新博客，又不想这篇文章拖的太久，所以我总结了两点比较有价值的地方分享给大家，目的不是让大家能会使用DDD来设计系统，而是能有一个突破点来衡量DDD到底比传统三层好在哪里，因为大部分人还没有DDD的开发经验所以能体会到应该没有相关途径； 阅读全文

摘要： 这一篇文章我早准备写的，迟迟未写的原因是它过于抽象不太容易表达，也很难掌握；之前对它的理解还处于比较简单的功能性上，但是最近随着对领域驱动设计及架构的研究，设计思想有了一个提升对它的理解也有了一个更清晰的轮廓，所以才敢下手去写，这么好的一篇文章不能搞砸了； “钝化语句” 简单描述：将基于栈的调用抽象成基于我们自己构建的虚拟运行时调用； 阅读全文

摘要： 通过上一篇的“.NET框架设计—常被忽视的C#设计技巧”一文来看，对于框架设计的技巧还是有很多人比较有兴趣的，那么框架设计思想对于我们日常开发来说其实并不是很重要，但是对于我们理解框架背后的运行原理至关重要；当我们使用着LINQ灵活的语法的同时我们是否能理解它的背后运行原理、设计原理更深一点就是它的设计模式及复杂的对象模型； 从一开始学习.NET我就比较喜欢框架背后的设计模型，框架提供给我们的使用接口是及其简单的，单纯从使用上来看我们不会随着对框架的使用时间而增加我们对框架内部设计的理解，反而会养成一样拿来即用的习惯，我们只有去了解、深挖它的内部设计原理才是我们长久学习的目标；因为框架的内部设计模式是可以提炼出来并被总结的； 这篇文章总结了几个我最近接触的框架设计思想，可以称他们为模式；由于时间关系，这里只是介绍加一个简单的介绍和示例让我们能基本的了解它并且能在日后设计框架 阅读全文

摘要： 本文中的内容都是我无意中发现觉得有必要分享一下的设计经验，没有什么高深的技术，只是平时我们可能会忽视的一些设计技巧；为什么有这种想法是因为之前跟一些同事交流技术的时候会发现很多设计思维被固化了，比如之前我在做客户端框架开发的时候会去设计一些关于Validator、DTO Transfer等常用的Common function，但是发现在讨论某一些技术实现的时候会被弄的云里雾里的，会自我郁闷半天，不会及时的明白对方在说的问题； 后来发现他们一是没有把概念分清楚，比如.NETFramework、C#、VisualStudio，这三者之间的关系;二是没有理解.NET中各个对象的本质含义，比如这里的特性(Attribute)，大部分人都认为 阅读全文

摘要： 在开始这篇富有某种奇妙感觉的文章之旅时我们先短暂的讨论一下关于软件开发方法论的简要： 纵观软件开发方法论，从瀑布模型、螺旋模型、RUP(统一软件开发过程)、XP(极限编程)、Agile(敏捷开发)一路走来，他们的好他们的美，我想接触过的人都会口口称赞，都是大师们一身的经验结晶最后沉淀为专业的技术方向、技术领域，带领我们软件开发者们永无止境的前进，目睹一场又一场的美景一桌又一桌盛宴。他们在不断的开辟新的领域，称为伟大的科学家一点都不为过。 阅读全文

摘要： 原则对于任何一项技术实现来说都是至关重要的，在设计某一个系统功能的时候我们讲究的是设计原则： 【单一职责原则Single Responsibility Principle、里氏替换原则Liskov Substitution Principle、依赖倒置原则Dependence Inversion Principle、接口隔离原则Interface Segregation Principle、迪米特法则Law Of Demeter、开闭原则Open Close Principle】。 在架构设计的时候我们也讲究架构原则： 阅读全文

摘要： 最近在研究DDD颇有收获，所以整理出来跟大家分享，共同进步！ 我们在设计业务系统的时候都会存在一个非常棘手而又无法回避的问题“业务扩展性”、“业务灵活性、”面向对象化“，尽管我们熟练掌握设计思想、设计模式、设计原则等等关于如何设计灵活性的系统设计理论，但是我们似乎都没有将它们运用到真正业务系统设计、开发当中去，为什么？这样的疑问如果对有心想设计好系统的朋友来说肯定是很早就出现过，只是无法解决，因为我们目前使用的设计方法是与面向对象设计背道而驰的。 阅读全文

摘要： 在看本篇文章之前我假设您已经具备我之前分析的一些原理知识，因为这章所要讲的内容是建立在之前的一系列知识点之上的，为了保证您的阅读顺利建议您先阅读本人的LINQ系列文章的前几篇或者您已经具备比较深入的LINQ原理知识体系，防止耽误您的宝贵时间。 到目前为止我们对LINQ的执行原理已经很清楚了，从它的前期构想到它真正为我们所用都有足够的证据，但是似乎问题并没有我们想的那么简单，问题总是在我们使用中频频出现尤其是新技术的使用，当然有问题才能有进步。 阅读全文

摘要： #2013微软MVP社区巡讲#欢迎热爱微软技术的开发人员和IT专业人士参与“新年新期待”2013微软MVP新年社区巡讲。微软最有价值专家MVP将在2013年伊始到访美丽上青岛，帝都北京，泉城济南。微软专家，明星讲师为您倾情奉献Windows 8， Windows Phone， New Office技术课程，参与活动您将会与专家们进行面对面的交流。一个下午的时间轻松掌握技术握住新年礼物。 阅读全文

摘要： 这个主题扯的可能有点远，但是它关系着整个LINQ框架的设计结构，至少在我还没有搞懂LINQ的本意之前，在我脑海里一直频频出现这样的模型，这些模型帮助我理解LINQ的设计原理。其实在最早接触环路模型和碎片化模型是在前两个月，那个时候有幸接触企业应用架构方面的知识，里面就有很多业务碎片化的设计技巧。其实理解这些所谓的设计模型后将大大开阔我们的眼界，毕竟研究框架是要研究它的设计原理，它的存在必然是为了解决某一类问题，问题驱动它的设计模型。所以我们在研究这样的模型的时候其实已经在不知不觉的理解问题的本质。 阅读全文

摘要： 在开始看本篇文章之前先允许我打断一下各位的兴致。其实这篇文章本来是没有打算加“开篇介绍”这一小节的，后来想想还是有必要反馈一下读者的意见。经过前三篇文章的详细讲解，我们基本上对LINQ框架的构成原理有了一个根本的认识，包括对它的设计模型、对象的模型等，知道LINQ的查询表达式其实是C#之上的语法糖，不过这个糖确实不错，很方便很及时，又对一系列的LINQ支撑原理进行了大片理论的介绍，不知道效果如何； 阅读全文

摘要： 什么是动态LINQ查询？LINQ的编写是静态的，因为C#是基于静态类型系统原理设计的，在编写时已经确定类型，也就是在编译时就已经知道将要执行什么样的查询，条件是什么、排序方式是什么等等。那么很大一部分应用场合中我们需要根据用户的选择来查询数据源，以往我们都是通过判断的方式来拼接查询的SQL字符串，但是现在我们面对是强类型的LINQ查询，是否可以很方便的进行类似查询。其实也没有什么好神秘的，基本的实现原理是通过动态的构建表达式树来实现IQueryable接口的查询。 阅读全文

摘要： 到了这里我们似乎隐隐约约的能看见LINQ的原理，它不是空中花园，它是有基础的。在上面的一系列新特性的支持下，微软通过大面积的构建扩展方法使得上述特性能连贯的互相作用，形成自然的集成查询框架。上面的这些特性都属于语言为了LINQ而做的增强，也可以说是设计者们在不断的探索新的比较符合现代开发体系的语言特性，也越来越多的支持函数式的编程特性，比如DLR的引入对Python、Ruby函数式脚本语言的强大支持，后面也会越来越多的支持其他的函数式脚本语 阅读全文

摘要： LINQ简称语言集成查询，设计的目的是为了解决在.NET平台上进行统一的数据查询。 微软最初的设计目的是为了解决对象/关系映射的解决方案，通过简单的使用类似T-SQL的语法进行数据实体的查询和操作。不过好的东西最终都能良性的发展演化，变成了如今.NET平台上强大的统一数据源查询接口。 我们可以使用LINQ查询内存中的对象(LINQ to Object)、数据库(LINQ to SQL)、XML文档(LINQ to XML)，还有更多的自定义数据源。 阅读全文

摘要： 在本人的.NET面向上下文、AOP架构模式（概述）一文中，我们大概了解了上下文如何辅助对象在运行时的管理。在很多时候我们急需在运行时能把对象控制在一定的逻辑范围内，在必要的时候能让他们体现出集中化的概念，如人群、车辆、动物等等。而Context与AOP有着密切的联系，Context表示逻辑抽象的范围而AOP描述了在这个逻辑范围内如何进行控制。其实这两者都是设计模式外的设计模式，与具体的技术实现无关。[王清培版权所有，转载请给出署名] 阅读全文

摘要： 上下文：其实就是一个逻辑上的业务、功能区域。在这个逻辑区域里可以有效的进行管理，算是一种制度的约束，也可以理解为某种范围类的数据共享。 其实在很多应用框架中到处可以看见上下文的概念，包括.NET本身的设计就建立在这种思想上的。实例化的对象默认存在于系统中的默认上下文中，我们可以构建自己的上下文将对象在运行时进行合理的管理。 在ASP.NET框架中比较经典的就是HttpContext上下文对象。所有的运行时对象都..... 阅读全文

摘要： 前段时间一直在学习和研究.NET事务处理，慢慢的我发现可以使用事务处理来实现一种可逆的系统框架。这种框架在一些IT社区似乎还没有见过，但是在我们日常开发中确实有这个需求。所以我花了点时间深入的研究了一下事务的原理和使用，实现了以事务为纽带，以资源为操作对象的可逆框架。 这里我假设您对事务有了整体的认识，也对自定义事务管理器有过了解。[王清培版权所有，转载请给出署名] 阅读全文

摘要： 最近一边参与公司的项目开发，一边还肩负着基础库的创建和维护。真真切切的体会到写框架的不容易，写出好的，方便使用的框架更不容易，需要考虑的东西太多，需要掌握的东西太多。不过不要紧我们正在前进的道路上。同志们一起加油！ 最近在使用存储过程的时候总觉得有点麻烦，尽管在前期对ORM和统一数据源接口封装已经下了很多功夫，对IDataParameter之类的接口已经进行了很好的封装，但是还是觉得麻烦。[王清培版权所有，转载请给出署名] 经过与DBA的沟通，他认为对存储过程的封装是有必要的，以他十几年的经验看，存储过程后期的移植是必不可少的。现在的项目是用SQLSERVER2008开发的，后期可能会移植到ORACLE上去，那么对存储过程的编写DBA考虑很周全。但是对于程序员来说，经验稍微丰富点的可能会通过某种工厂将具体对 阅读全文

摘要： 最近一直忙于新公司的基础库建设和一些业务系统的开发，接触到了一些比较有思想的技术人员，在他们身上发觉到了很多值的深思的话题，也领悟到了一些比较有价值的经验在此与同行们分享一下也算是探讨一下吧；[王清培版权所有，转载请给出署名] 都说技术人员应该重视业务的学习和培养，只有精通业务了才能更好的发挥技术。其实我是不太赞成这句话的，为什么？从我的个人经历和经验来看，这是对的。当然世事无绝对，站在我们程序员的角度讲，我绝对建议技术人员始终要以技术为主业务为辅的观点。可能有些朋友要来火了，技术辅助业务应该是业务大于技术，凡事都是相对的。如果以业务为主，就等于把自己的小命送给公司管了，如果以技术为主那么小命还是自己保管的。这句话经历过的人才会懂，我就不解释了。 阅读全文

摘要： 这篇文章讨论的概念其实比较简单的，但是在实际的项目应用中非常的重要和普遍。 我们的项目一般都是采用分层架构，有的三层有的可能五层或者其他的方式组织系统的架构，但是始终要将系统的架构按照模式设计，我们才能重用和接受维护。 随着ORM的流行和大面积的使用，行业内出现各种各样的ORM框架，有自己开发的有大型的软件公司开发的，基本在使用上都遵循了以实体为中心的概念，也就是围绕关系数据库中的表为操作对象。复杂的可能还包括连接查询多表操作等等。[王清培版权所有，转载请给出署名] 按照分层架构设计中的指导约束，我们应该尽可能的在系统模块之间采用Entity进行数据的传递。当然世事无绝对特殊性的项目可能没有这么简单 阅读全文

摘要： 最近一直在忙新公司的基础库建设，对系统架构、开发框架及快速开发平台的设计实施都积累了一定的实践经验。 一般的中小型的软件开发公司，如果按照技术储备来衡量软件项目的技术含量的评定依据是可行的。但如果光是按照人头来衡量软件的技术含量是不可靠的。所以我们在选择跳巢的时候是选择大公司还是选择有技术含量的公司要根据自己的职业规划来。(本人最近体会到的一点跳巢经验分享给大家) 由于我现有单位技术部门刚刚成立不久，需要一些基础的开发框架，ORM当然是跑不了的。在后面的文章中我将陆续写下我在建设基础框架中的一些实践检验，里面可能包括对UI层的封装、基础控件的封装等等。我就废话少扯了，进入主题。 这篇文章的重点是无反射的ORM框架，为什么会有这样的想法？其实前不久群里的朋友就问了一些问题，他们在构建自己的ORM框架的时候频繁的在使用反射来编写功能。从跟他们的交流上来看他们似乎很喜欢使用反射来写功能，但是没有仔细的研究过 阅读全文

摘要： 在本人最近的几篇关于事务处理的文章中，从事务处理的整体概念到具体的C#代码的实践操作基本上都已经能满足日常的开发需求。文章中大部分的事务范围类的操作都是局限于数据库，在本人的“.NET简谈自定义事务资源管理器 ”一文中我虽然实现了一个简单的自定义资源管理器，其实也能满足基本的项目需求，核心功能也实现了，但是对于文件事务操作我们是力不从心的。[王清培版权所有，转载请给出署名] 从数据库到自定义资源管理器都能参与到事务处理中来，在必要的时候保证数据的完整性，那么我们缺一个类型的资源操作，当然您也许早就想问了，关于文件系统的事务操作怎么办？那么关于文件的事务操作是否有成熟的解决方案了，这点在前几年还真没办法，但是最近微软已经发布了关于事务性NTFS系统。都了解NTFS文件系统的优势和好处，比起FAT和其他的什么HPFS文件系统有极大的改进，所以文件事务处理仅支持NTFS格式的文件系统。 阅读全文

摘要： 在上一篇文章“NET简谈事务、分布式事务处理”中我大概总结了关于.NET中的事务处理方式和结合了WCF框架的简单应用。在事务性操作中我们的重点是能将数据进行可逆化，说白了就是能保证数据的ACID（关于事务的整体模型、原理请参见“.NET简谈事务本质论”一文），在.NET事务处理框架中强大的类库帮我们实现了很多事务传递、事务自动提升的技术难点，同时也提供了很多扩展接口，只要我们肯去研究总能有收获。 这篇文章主要讲解怎样利用.NET为我们提供的扩展接口进行自定义的事务处理范围内的资源管理，在事务的操作范围内我们不会总是将数据库视为依赖的对象，也不会总是IdbTransaction之类的对象，我们需要自己的事务性资源管理器，我们需要自己的持久性资源管理器。在可能的情况下我们需要自己开发后备持久存储区..... 阅读全文

摘要： 在本人的 “ .NET简谈事务本质论”一文中我们从整体上了解了事务模型，在我们脑子里能有一个全局的事务处理结构，消除对数据库事务的依赖理解，重新认识事务编程模型。 今天这篇文章我们将使用.NET C#来进行事务性编程，从浅显、简单的本地事务开始，也就是我们用的最多的ADO.NET事务处理，然后我们逐渐扩大事务处理范围，包括对分布式事务处理的使用，多线程事务处理的使用。 数据库事务处理 数据库事务处理我们基本都很熟悉了，begin Transaction ……end Transaction，将要进行事务性的操作包在代码段里，为了便于文章有条理的讲解下去，我还是在这里穿插一个简单的小示例，便于与后面的代码进行对比分析 阅读全文

摘要： 这篇文章主要介绍一下事务处理的本质。 其实事务处理对我们来说并不陌生，但是很多人对事务处理的理解似乎有点弄不清，觉得事务处理只存在于数据库中。导致这样的结果是有原因的，当我们开始准备学习编程的时候，都是从某些编程语言开始学起，而不像人家的国外会先从概念、原理、模型开始学习，所以我们都会将某些技术与一些语言、平台联系在一起，导致我们学习其他的语言或者平台会很吃力。 在学校里也好还是自学也好，为了很快的上手都会去学习一些工具然后才会慢慢的去学习跟我们日常开发有关系的技术，仅仅是技术实现而不会去追根究底的问“为什么”。其实作为我们软件开发人员来说，为了跟好的发展需要有一个从概念、原理、技术实现这样的一个正确的学习方法或者说是一种梳理过程，只知其然而不知其所以然，这样会很困惑。 进入主题...... 阅读全文

摘要： 在本人的上一篇文章中只是简单的介绍了一下.NETRemoting的一般概念和基本的使用。这篇文章我想通过自己的学习和理解将对.NETRemoting的整体的一个框架进行通俗的讲解，其中最重要的就是信道(管道)处理模型思想，这里面蕴含了很多的设计原理。[王清培版权所有，转载请给出署名] .NETRemoting远程处理架构是一个半成品，是.NET给我们的扩展框架，要想用于商业项目必须进行一些安全、性能方面的控制。要想进行一定深度的扩展那就要必须了解它的整体结构，各个点之间的关系才能很好的控制它。 网上讲解.NETRemoting的文章很多，但是通俗易懂的没有几篇，都是大概讲解了一下整体模型或者从MSDN上COPY过来，未能对各模型之间的接口做详细讲解........ 阅读全文

摘要： 这篇文章我们来简单的了解一下在.NET平台上有一个强有力的远程调用武器，也是上一篇文章中我一笔带过的远程英雄.NetRemoting。 其实在.NET平台里面到处都能看见Remoting的影子，只不过我们平时都很少有机会与它接触，因为它通常工作于“后端”，躲在界面显示技术(如：Winform\Asp.net\Wpf.) 界面显示层是将信息以友好的方式展现在用户面前，但是真正的英雄通常都在背后默默的支持它，以更华丽的效果展现。(如：Thread\WebService\Remoting\Wcf...)。 其实在我们不断学习的过程中会慢慢的在我们脑海里浮现出我们所学习的东西的模型，比如我们是专研.NET这门技术，那么在我们脑子里是否已经有了一个简单而模糊的阴影，能看见这种阴影才证明我们刚刚入门。如果未曾有....... 阅读全文

摘要： 在.NET1.0版本出来的时候，要想进行远程调用基本上都是通过WebService的方式。而随着.NET2.0版本的出现，我们可以通过一个更加方便且高扩展性的框架来进行编写远程调用的程序，也就是我们都比较熟悉的.NetRemoting。 网上对.NetRemoting技术讲解的文章不计其数，但是很少有一本比较全面的、系统的学习书籍。我们都是从哪些零散的知识里慢慢摸索，效果不太理想。 今天我也来简单的介绍一下我理解的Remoting。不仔细研究一下还真不知道它的厉害，完全的托管平台、高扩展性、灵活性。框架完全采用面向接口编程，任何一个点我们都能提供自己的实现，信道、格式化器、租约、赞助方等等，系统都为我们预留了扩展的接口。[王清培版权所有，转载请给出署名]....... 阅读全文

摘要： 最近在苦学.NET底层框架模型，发现.NET深入真的不是一般的难，不开源、没有相关系统的官方的书籍做学习资料，只能零散的看MSDN。要想摸熟.NET的模型真的并非易事。慢慢来吧。[王清培版权所有，转载请给出署名] .NET应用程序域(AppDomain)是我们所有.NET应用程序的逻辑宿主容器。初次接触会感觉到AppDomain离我们日常开发比较远，不常用到。其实是我们很少接触一些复杂而底层的系统结构。在日常的开发中，我们多数是基于数据库的管理信息系统(MIS)，做增、删、改、查的操作。我始终认为作为开发人员要注意自己的发展方向，要时刻提醒自己的职业规划，不要盲目的将自己的黄金时间用在“寻找另一艘行驶很慢的小帆船上”...... 阅读全文

摘要： 在本人的上一篇文章“.NET简谈组件程序设计之(初识序列化、持久化) ”中，我们基本上了解了什么叫序列化和持久化。通过系统为我们提供的服务，我们可以很方便的进行二进制序列化、SOAP协议序列化。 今天这篇文章是来讲解怎么运用一些高级的功能，在序列化、反序列化过程中进行一些控制。[王清培版权所有，转载请给出署名] 这里穿插一句题外话：其实在我们自己编写组件的时候真的有好多东西可以借鉴.NET平台的一些优点，它的功能都不是死的，可以订阅、可以切入，在我们编写组件的时候，我们其实也要好好考虑一些高级的特性。 上面这段话其实是为了铺垫用的，意思是说序列化组件在它工作的时候我们可以“参合”进去..... 阅读全文

摘要： 今天我们来学习在组件开发中经常用到的也是比较重要的技术“序列化”。 序列化这个名词对初学者来说不太容易理解，有点抽象。我们还是用传统的分词解释吧，肯定能搞懂它的用意是什么。 解释：数学上，序列是被排成一列的对象（或事件）；这样，每个元素不是在其他元素之前，就是在其他元素之后。这里，元素之间的顺序非常重要。 那么我们对照这样的解释来分析一下我们程序中的序列化什么意思。都知道对象的状态是在内存中实时存着的，对象的状态在初始化的时候是通过系统分配的，在后期的程序运行过程中可能对它进行过一些修改，那么我们怎样将这些状态保存下来供下次使用呢。[王清培版权所有，转载请给出署名]..... 阅读全文

摘要： 在上一篇文章“.NET简谈组件程序设计之(上下文与同步域) ”中，我们学习了关于一些上下文和同步域的概念，可以利用这两个技术来进行自动同步。 今天我们主要学习怎么手动来执行同步，能从更小的粒度进行封锁，以达到最大程度的吞吐量。[王清培版权所有，转载请给出署名] 我们知道线程是进程的运行实体，进程是资源分配单位，而线程是执行单位。照书上所说，线程是程序的执行路径，当我们分配一个线程的时候，要确定线程的执行路径是什么，也就是代码中的ThreadStart委托所指向的入口点方法。 一旦我们手动Start启动线程的时候，当前上下文线程就被系统立即切换，我们从Thread.CurrentThread静态属性中可以准确的获取到当前正在执行的线程实例，然后进行一系列的设置、等待、终止。[王清培版权所有，转载请给出署名]..... 阅读全文

摘要： 我们继续学习.NET多线程技术，这篇文章的内容可能有点复杂。在打破常理之后，换一种新的思考模型最为头疼。这篇文章里面会涉及到一些不太常见的概念，比如：上下文、同步域等等。我也是最近才接触这些关于组件编程方面的高深技术，大家一起学习，再大的困难也是有时间限制的，只要我们坚持。 在本人的上一篇文章“.NET简谈组件程序设计之(多线程与并发管理一)”中，只是初步的带领我们学习一下关于多线程的一些基本的原理，包括线程切换，线程的开始、执行、等待、结束。 这篇文章的重点是学习关于线程的同步、互斥的机制。在多线程的应用程序中，最少会有一个主线程在运行着，如果我们想提高应用程序的吞吐量就必须借助多线程的原理来实现。[王清培版权所有，转载请给出署名].NET上下文(ContextBoundObject对象)...... 阅读全文

摘要： 由于多线程的内容比较多我会用几篇文章来讲解。 多线程在我们日常开发过程中用的很多，上一篇“.NET简谈组件程序设计之(异步委托)”详细的讲解了基于委托的多线程使用，委托是基于后台线程池的原理，这篇文章将主要介绍直接使用Thread对象来实现多线程。 当然使用Thread没有使用Delegate那么容易，毕竟多线程跟异步调用是两个相差很大的技术方向，我也是略懂点皮毛，在此献丑给大家，如有讲的不对的地方还请指出。[王清培版权所有，转载请给出署名] 我们先来理解几个概念，以方便我们学习。 后台线程与前台线程 前台线程：什么叫前台线程，就是我们使用默认的Thread创建出来的没有进行IsBackground属性设置的都是前台线程，因为默认IsBackground是false。前台线程是明确任务的，也就是任何一个前台线程没有结束之前程序是不会自动退出的，除非强制关闭应用程序...... 阅读全文

摘要： 说到委托我想大家基本上都用过的，今天这篇文章就来讲解关于委托的异步奥秘。 在我们正常使用的时候很少会去用异步委托技术来提高代码效率。委托的好处就是能对方法进行面向对象的封装，随意传递。在任何组件客户代码中都能对其进行调用，而不是传递方法对象的引用，这样能大大的降低代码的耦合。事件就是运用委托的优势进行对象的消息传递。。[王清培版权所有，转载请给出署名] 那么什么是异步委托呢？简单点讲就是异步的调用一个方法，但是如果我们直接用工作线程(main入口进行来的)去调用方法的话，肯定是做不到异步的。想要异步调用必须用子线程去完成，让主线程能处理一些关键的事情，比如用户界面响应、按钮事件的处理。不能让用户等待这是原则。 下面我们就来学习关于异步委托的相关技术。 我们先看一段简单的代码........ 阅读全文

摘要： 本人最近一段时间在学习关于.NET组件编程方面的技术，在学习过程中确实有很多好的东西需要与大家分享。[王清培版权所有，转载请给出署名] 关于什么叫组件编程，其实就是利用.NET来开发基于组件模型的程序，面向组件编程而非面向对象编程，这是一个高度，没有很长时间的学习与磨练 是体会不到这个感觉的。我们现在的开发思想应该是以面向对象为主的，但是如何提升这个高度，只有慢慢的学习了。 其实面向组件编程包含了面向对象编程思想，将一组功能独立的封装起来供以后重复使用，但是在开发组件的过程中需要使用到面向对象的思想来构 造组件，这两个概念不矛盾，面向对象思想是具体实现，而面向组件思想应该说是站在一个产品或者说是一个框架的高度来宏观的形容...... 阅读全文

摘要： 我们继续学习设计模式系列文章。 今天我们要学习的是设计模式中的适配器模式，适配器模式其实也比较好理解，光从它的名字我们都能理解个所以然了。 适配器模式定义：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 上面的这段话可能对初学者来说有点抽象，短短的一段话提到了几个关键的技术点。都是一些基本语法，如果我们还没有掌握这些语法最好还是先去解决前提再来攻克设计模式。 那到底啥叫适配器模式，这个“适配”很形象、生动的形容了所表达的意思，那么一般用在什么地方呢？怎么来解决一些接口不兼容的情况下的问题。下面我们就来由浅入深的进行理解、学习。[王清培版权所有，转载请给出署名]..... 阅读全文

摘要： 我们继续学习设计模式系列文章。 本篇要讲的是命令模式，其实命令模式也比较好理解，没有用到多高深的技术，也不需要多复杂的抽象。只需要我们脑海里能有一个大概的原型，等我们遇见类似问题的时候我们能通过巧妙的方式来解决。我们做应用层开发的大部分接触的都是一些模式、框架、思想等等，不像搞低层开发的，他们研究的可能多数是一些技术实现的问题，而我们是学习实现的方法论。应用层开发在技术的复杂程度上是有限的，在组合技术的实现上是复杂的。所以有一些.NET架构师确实比较厉害，他们能很早的就料到会出现什么问题，他们有很强的架构思想，对设计模式的掌握、对架构设计思想、对敏捷、极限...... 阅读全文