摘要： 面向EDA（事件驱动架构）的方式来设计你的消息 AMQP routing key的设计 RabbitMQ cluster搭建 Mirror queue policy设置 两个不错的RabbitMQ plugin 大型应用插件(Sharding、Rederation) Queue镜像失败手动同步 各集 阅读全文

摘要： 最近的工作我在做一个有关于消息发送和接受封装工作。大概流程是这样的，消息中间件是采用rabbitmq，为了保证消息的绝对无丢失，我们需要在发送和接受前对消息进行DB落地。在发送前我会先进行DB的插入，单表插入，所以在性能上也是能接受的，单表插入做了压测基本上是一到两毫秒的时间，加上消息的发送（有ACK）再加上集群是两个节点的高可用（一个磁盘持久化节点），单台TPS基本上是在2000-3000左右。这对于我们的业务场景来说是够用了。一旦当消息丢失或者由于网络问题、集群问题业务不会中断，消息就算发不出去也没关系，我们会进行消息的补偿或者同步api调用补偿。这是架构设计的必须要考虑的A计划、B计划、C计划，这是敬畏或者危机意识。 阅读全文

摘要： 最近在使用log4net的时候有一个简单的需求，就是自定义个格式化输出符。这个输出符是专门用来帮我记录下业务ID、业务类型的。比如，“businessID:328593,businessType: orderID”。类似这样的输出日志。这些日志会被elk agent提取送到日志中心ES中，用来进行辅助排障。 简单的看了下log4net的PatternLayout和PatternConverter两个对象的作用，实现起来也是非常方便的。log4net有一组global的PatternLayout，这些全局的格式化对象是默认构造的时候就存在了，我们只需要提供对我们来说特殊场景的实现即可。 阅读全文

摘要： 在使用git的时候，不管你的服务器是开源平台github还是私服gitlab，你都需要clone仓库到本地，这个clone的时候就需要你选择连接方式。这个连接方式决定了你与服务器交互的时候以一个什么协议进行。如果你没搞清楚这两种方式，可能你在使用的时候会很困惑，别人在push代码的时候没有提示输入账号密码，而你却有，至少我当初有过这个问题。 可选择的协议有https、ssh两种，这从git repository仓库的地址就能分辨出来。 阅读全文

摘要： 从事.NET开发到现在已经有七个年头了。慢慢的可能会很少写.NET文章了。不知不觉竟然走了这么多年，热爱.NET热爱c#。突然想对这一路的经历进行一个总结。 是时候开始下一阶段的旅途，希望这些文章可以在发挥点价值作用。 架构设计： ElasticSearch大数据分布式弹性搜索引擎使用 （推荐） D 阅读全文

摘要： 在你经常使用的命令当中有一个git branch –a 用来查看所有的分支，包括本地和远程的。但是时间长了你会发现有些分支在远程其实早就被删除了，但是在你本地依然可以看见这些被删除的分支。 你可以通过命令，git remote show origin 来查看有关于origin的一些信息，包括分支是否tracking。 阅读全文

摘要： 有一种场景是经常发生的。 大家都基于develop拉出分支进行并行开发，这里的分支可能是多到数十个。然后彼此在进行自己的逻辑编写，时间可能需要几天或者几周。在这期间你可能需要时不时的需要pull下远程develop分支上的同事的提交。这是个好的习惯，这样下去就可以避免你在一个无用的代码上进行长期的开 阅读全文

摘要： 你经常会面临着将dev分支或者很多零散的分支merge到一个公共release分支里。 但是有一种情况是需要你处理的，就是在你的dev的分支里有很多commit记录。而这些commit是无需在release里体现的。 develop 主分支 develop主分支最近的一个commit是”fix im 阅读全文

摘要： 聊下 git rebase -i 聊下git merge --squash 阅读全文

摘要： 在使用git作为源代码管理工具的时候，开发的时经常会面临一个常见的问题，多个commit 需要合并为一个完整的commit提交。 在一个基本的迭代周期里，你会有很多次commit，有跟配置文件相关的，有跟代码相关的，甚至有跟下次发布fixbug相关的。这些都是你在完成本地开发的时候一个变化记录而已。 阅读全文

摘要： 阅读目录： 背景 安装 查找、下载rpm包 、执行rpm包安装 配置elasticsearch专属账户和组 设置elasticsearch文件所有者 切换到elasticsearch专属账户测试能否成功启动 安装自启动elasticsearch servicewrapper包 下载elasticse 阅读全文

摘要： DDD本身的技术就不介绍了，本篇文章要分享下我在推广DDD或者说实施DDD的过程中的心得和宝贵的经验。事实证明，这是可行的方案。用好DDD是一回事，推广DDD是另外一回事。也许已经有一套客观理性的推广技术的方案，但是我只能说DDD非常特殊。 我们都知道自己用好DDD问题不大，让一两个人用好DDD也问题不大。你也许代码控制能力很强，也或者你的组员对DDD都有兴趣，在你的领导下，你让他们编写DDD模式的代码，问题也不大。但是作为一名架构师我们的职责是要推广或引进适合本公司业务模式的某种技术或者最佳实践。你或许推广性能优化、界面设计等等，这都没问题。但是让你推广一些有着很强主观意识在里面的东西其实很难。因为每个人的思维模式不同，对 阅读全文

摘要： 这篇文章内容会很短，主要是想给大家分享下我最近在做一个简单的rabbitmq客户端类库的封装的经验总结，说是简单其实一点都不简单。为了节省时间我主要按照Library的执行顺序来介绍，在你看来这里仅仅是一个简单的经验总结，但是在我看来这些经验只有在你真正的封装rabbitmq客户端库的时候且将你的客户端安全稳定的发布上线后才会真的发现这些问题。 比如你的库只是链接单个Node的时候和链接高可用集群的HAProxy时候是完全两回事。当你未能在你的库里使用反向注入LOG接口的时候一旦在线上发生网络解析和序列化等一系列在线问题时候你是多么无能为力。当你使用同步循环获取队列消息的时候一旦发生异常你的链接就会断掉等等这些细节。我总结了我在编写这个library的时候慢慢稳定下来的过程和经验。至少目前来看网络上的文章，当然我是指.NET/C#方面的，都没有讲到这些问题，大 阅读全文

摘要： 最近对软件开发有了一个新的认识，这个认识源自连续看了两本Craig larman大师的书籍《UML与模式应用》、《精益与敏捷开发大型应用实战》和公司目前的项目情况这两件事情一起碰撞导致的感悟。 先说下前者，为什么会想到看Craig larman大师的书籍。其实我收藏的书籍已经上千本，在各个电商平台上都有帐号，目的只有一个就是收藏好的书籍。家里也堆了很多，没事浏览新书是我现在最大的乐趣。我相信有这种感觉和爱好的不止我一个人，家里堆上几十本书的在IT行业算是很正常的。 书多了有时候不知道要看些什么也很正常，我的原则就是随时调整，看目前所面临的困惑。根据我以往的经验总结，在实际问题面前寻找答案最容易让你有新的感悟和提升。我相信书中自有黄金屋、书中自有颜如玉，要在对的时间看对的书，说白了就是在有困惑的时候就去寻找给你答案的这方面书籍。为什么要看Craig larman大师的书，是因为 阅读全文

摘要： 最近一段时间都在做系统分析和设计工作，面对的业务是典型的重量级企业应用方向。突然发现很多以往觉得很简单的问题变得没有想象的那么容易，最大的问题就是职责如何分配。论系统架构设计的最大的问题，其实也就是职责的分配，分配的合理，实现起来就会很柔性，反之就会使架构很混乱。 软件的生命周期大概可以归纳为四个基本的过程，分析、设计、实现、测试，当然这仅仅是一个最为粗略的表示而已。不同的方法论有着不同的使用这几个过程的方式。RUP使用快速迭代的过程，在这个几个子过程中适当的输出一些过程制品，每次迭代都是进行相同的分析、设计、实现、测试。而在Scrum中，不提倡输出任何文档形式的过程制品，也同样有着上述几个过程，强调以人为中心，通过沟通来解决大部分的问题。 不能用好与不好来判断哪一种方法论，只能根 阅读全文

摘要： 很高兴我的第一本书由图灵出版社出版。本书总结了我这些年来对框架学习、研究的总结，里面纯干货，无半句废话。 书的详情请看互动网的销售页面：http://product.china-pub.com/3770890 精彩推荐： “这本书最大的价值就在于告诉你如何在实战中运用平时学到的知识，如何站在不同的角度分析和解决问题。与市面上其他图书不同，这本书中的内容都是清培在工作中遇到实际问题后分析得出的经验。对我而言，里面的各种设计都具有独到的见解，往往能将复杂的问题简化成优雅的模式。” 　　——刘星亮，携程旅行网攻略社区事业部技术经理、架构师 　　 　　“这本书字里行间都充满了高大上的气息，但又有一种低奢内的大家风范。实在是一本在架构设计方面实用的经验之书、智慧之书。” 　　——袁永福，微软MVP、南京都昌信息科技有限公司创办人 阅读全文

摘要： 随着应用程序的复杂度不断上升，要想将好的设计思想稳定的落实到线上，我们需要具备解决问题的能力。需要具备对运行时的错误进行定位且快速的解决它的能力。本篇文章我将分享一下我对.NET应用程序调试方面的学习和使用总结。 其实对调试程序的使用是不难的，关键是知道它的调试原理才行，因为调试一个程序或者dump文件，都需要了解一定的.NET调试的原理才行，比如你在附加到进程调试时在执行某个SOS扩展命令是需要切换到指定线程上的，而调试dump文件就不需要，但是对Dump文件的分析有些SOS扩展命令是不能用的，类似这样的问题，一旦出现你就一头雾水，所以花点时间学习一下原理是有必要的。 阅读全文

摘要： 从这篇文章开始我将分享一系列我认为在实际工作中很有必要的一些.NET项目开发的核心技术点，所以我称为必知必会。尽管这一些列是使用.NET/C#来展现，但是同样适用于其他类似的OO技术平台，这些技术点可能称不上完整的技术，但是它是经验的总结，是掉过多少坑之后的觉醒，所以有必要花几分钟时间记住它，在真实的项目开发中你就知道是多么的有帮助。好了，废话不说了，进入主题。 我们在开发服务时为了调试方便会在本地进行一个基本的模块测试，你也可以认为是集成测试，只不过你的测试用例不会覆盖到80%以上，而是一些我们认为在开发时不是很放心的点才会编写适当的用例来测试它。 阅读全文

摘要： 随着现在的企业应用架构都在向着SOA方向转变，目的就是将一个庞大的业务系统按照业务进行划分，不管从公司的管理上、产品的开发上，这一系列流程来看，都是正确的。SOA确实带来了解决现在大型企业级应用系统快速膨胀的解决办法。 但是本文要说的是，我们都将目光转向到了后端，也就是服务端，而将精力和时间都重点投在了后端服务的架构设计上，渐渐的忽视了显示端的架构设计。然而显示端的逻辑也越来越复杂，显示端轻薄的架构其实已经浮现出难以应付后端服务接口快速膨胀的危险，服务接口都是按照指数级增加，基本上每一个新的业务需求都是提供新的接口，这没有问题。按照服务的设计原则，服务接口就应该有着明确的作用，而不是按照代码的思维来考虑接口的设计。 但是由此带来的问题就是组合这些接口的显示端的结构是否和这种变化是一致的，是否做好了这种变化带来显示端逻辑复杂的准备。 阅读全文

摘要： 一直都在谈论面向对象开发，但是开发企业应用系统时，使用面向对象开发最大的问题就是在于，多个对象之间的互操作需要涉及数据库操作。两个业务逻辑对象彼此之间需要互相调用，如果之间的互相操作是在一个业务事务范围内的，很容易完成，但是如果本次业务逻辑操作涉及到多个业务对象一起协作完成时问题就来了。 在以往，我们使用过程式的代码（事务脚本模式），将所有与本次业务事务范围内相关的所有逻辑都写在一个大的代码中，就算你适当的提取重复代码，效果也不大，因为你永远都.. 阅读全文

摘要： 对软件开发方法论有兴趣的博友应该发现最近“领域驱动设计”慢慢的被人发现被人实践起来，园子里也慢慢有了DDD的学习气氛和宝贵实战经验的分享。其实之前我也痴迷于DDD，为什么会痴迷于它并不是因为它是所谓的新技术，也不是因为各种对它的炒作，而是我觉得我找到了能解放我们进行企业业务系统开发的方法论。 DDD可以很好的指导我们开发可靠的软件系统，尤其是现在的企业业务复杂多变的情况下，使用DDD可以很好的随着业务变化不断的重构现有的领域模型，最为重要的是我觉得DDD是能够很好的实施敏捷价值观的软件开发方法论。 阅读全文

摘要： 要想正确的设计系统架构就必须能正确的搞懂每个架构模式的用意，而不是胡子眉毛一把抓。现在有一个现象是什么呢，项目的结构从表面上看是很不错，层分的很合理，其实对业务系统来说也就那么几种层设计方法，但是现在很多项目的逻辑架构的设计不是理想，有很多概念大家并不是很了解，当然也许每个人对技术的追求不同罢了。不管你追求不追求，事实我们还是要去往正确的方向努力才对的。 阅读全文

摘要： 接触分层架构有段时间了，从刚开始的朦朦胧胧的理解到现在有一定深度的研究后，觉得有必要将自己的研究成果分享出来给大家，互相学习，也是对自己的一个总结。 我们每天面对的项目结构可以说几乎都是分层结构的，或者是基于传统三层架构演变过来的类似的分层结构，少不了业务层、数据层，这两个层是比较重要的设计点，看似这两个层是互相独立的，但是这两个层如何设计真的还有很多比较微妙的地方，本文将分享给大家我在工作中包括自己的研究中得出的比较可行的设计方法。 阅读全文

摘要： 至今我都清楚的记得我第一次被面试官问起什么叫”建模“技术时的情景，那是好几年前的事情了，当时是胸有成竹的去面试一个有关系统分析、设计的.NET高级软件工程师岗位。面试官几乎没问我有关.NET方面的任何技术实现，他就简单的问了问：“你如何把握你所分析出来的系统的正确性？”，我当时有点小激动，觉得这个问题应该很简单嘛，都是概念而已，让他直接点问，结果他来一句：“你懂建模吗？，能给我解释一下建模的作用吗？“，接着他出了一个小例子，让我对这个例子进行建模，要考虑到各种扩展性、业务稳定性的关键点，要边建模边说出为什么要这么建模，要说出思路。他最后重点强调了一下：“创建出来的模型是不允许跟任何具体的代码、工具有关联的”。 阅读全文

摘要： 有一段时间没有更新博客了，最近半年都在着写书《.NET框架设计—大型企业级框架设计艺术》，很高兴这本书将于今年的10月份由图灵出版社出版，有关本书的具体介绍等书要出版的时候我在另写一篇文行做介绍。可以先透露一下，本书是博主多年来对应用框架学习的总结，里面包含了十几个重量级框架模式，这些模式都是我们目前所经常使用到的，对于学习框架和框架开发来说是很好的参考资料，大家敬请期待。 好了，进入文章主题。 最近几个月本人一直从事着SOA服务开发工作，简单点讲就是提供服务接口的；从提供前端接口WEBAPI，到提供后端接口WCF\SOAFramework，期间学到了不少有关多线程使用上的经验，这些经验有的是本人自己的错误使用后的经验，有些是公司的前辈的指点，总之这些东西你不遇到过你是不会意识到该如何使用的，所以本人觉得很有必要总结分享给广大和我一样工作在一线的博友们。 阅读全文

摘要： 由于博主今后一段时间可能会很忙（准备出书：《.NET框架设计—模式、配置、工具》，外加换了新工作），所以博客会很少更新； 在最近一年左右时间里，博主各种.NET技术类型的文章都写过，根据博友们的反馈觉得还不错，所以应该有整理一下目录的必要，防止随着时间的推移很多现在来说还比较新的技术文章到时候就不知名的石沉大海了；整理之后更方便大家查询，阅读，谢谢； 阅读全文

摘要： DomainModel是由很多细粒度的Object组成，按照以往的教训（将Object行为、数据肢解，得到一个残缺的Object），现在我们将逻辑行为和数据绑定在一起，形成了一个丰富的领域模型，这也是面向对象设计原则之一；想了解更多关于实现面向对象的技巧请参考【《实现模式》作者：Kent Beck】一书； 但是这样又带来了由于充血型DDD模型会给面向大规模查询的业务模块带来一定的性能开销，试想一个OrderManager对象，如果我们需要获取在某个条件范围类的所有Order会给OrderManager带来很多性能、逻辑上的复杂度；根据DDD.CQRS架构，得知将DomainModel中的查询逻辑单独剥离出去，让Command端很干净的处理聚合的写逻辑，在Query端也很直接的处理查询逻辑； 阅读全文

摘要： 现在越来越多的公司都在尝试SOA架构的实践，本人最近也在尝试学习这方面的技术，但是在实践过程中遇到一个问题，我想这个问题也是我们普遍实践者都应该会遇到的问题，问题描述如下： 我们有一个SOA商品（Item）查询接口，这个接口很通用，主要用来支撑日常很多其他系统的大量关于Item的查询，尤其是在高峰期间该服务的压力是很大的；我们站在SOA的角度看这个接口，这个通用的接口解决了众多的查询业务，确实不错，但是我们切换一下角度，站在每一个调用接口的访问端看似乎并不是很满意或者说牺牲了部分性能上的代价，因为我们无法干净利落的只获取当前这个业务点需要的数据项；这个Item服务接口所返回的数据项必须同时满足所有调用它的业务点，哪怕这次调用我只需要用到Item的三分之一的数据字段都不行，每次都会把不需要的字段都查询出来，不管是返回的性能、查询的性能，其实都是可以通过调整设计来避免的； 阅读全文

摘要： 使用ASP.NETMVC构建普通的中小型站点可以使用简单的Model元数据设置方式来控制ViewModel如何显示在View中，但是复杂的应用场景不会这么简单的就能完成；大型站点的ViewModel的体积非常大，真的大的超乎我们的想象（当然这里面有历史原因），这么大的一个显示实体我们需要在不同的页面中呈现它会非常的棘手；然而小型站点不太会遇见ViewModel在几十个页面中显示的情况出现，一般页面也就是几十个差不多了； 在大型电子商务应用中，UI层的一个ViewModel不仅用来呈现数据还充当着与远程SOA接口通讯的DTO作用，如果为了结构清晰完全可以将ViewModel与DTO分开，但是有时候我们确实需要考虑额外的性能开销（有时候我们只能接受历史遗留的问题，技术债务累积多久就要还多久）； 阅读全文

摘要： 在View中用来根据当前View中引入的强类型ViewModel生成HTMLDom结构的核心功能都被封装在以HtmlHelper为首的对象模型中，包括HtmlHelper泛型类型，它直接派生自HtmlHelper基类，这两个类型的功能都是围绕着如何生成前端所需要的HTML结构和一些常用的UI元素； 但是这两个类型所能做的事情很有限，它们只是庞大生成功能的核心模型；我们使用的都是围绕着这两个类型的扩展方法，如： @Html.EditorForModel() 在当前View中引用的Html属性其实是一个HtmlHelper类型的属性，定义代码： public HtmlHelper Html { get; set; } 该类型被定义在public abstract class WebViewPage : WebViewPage类 阅读全文

摘要： ModelMetadata是ASP.NETMVC中用来表示Model的元数据对象，它包含了一个Model的所有的相关元数据信息，当然这取决Model的使用方向，不同的使用方向会有不同类型的元数据，我们这里的ModelMetadata是针对View显示相关的元数据；ModelMetadata中绝大部分元数据是用来作为最终在View生成环节当中需要使用到的，比如：如何确定一个领域相关的属性（Address）该如何展现，这里的Address可能不是一个简单的String类型表示，而是由一组复杂的类型表示，这样的情况下我们就需要通过自定义元数据来控制最终使用的呈现模板（PartialView）； 在MVC的定义中，Model准确意思是ViewModel（显示Model，只是用来作为界面呈现使用的数据实体），它是直接提供给View作为呈现使用的数据实体，通常情况下还将作为DTO类型的数据实体，负责数 阅读全文

摘要： 这篇文章让我们一起来学习一下有关Asp.netMvc中的Mode元数据的相关设计和围绕元数据的一些其他对象模型，他们是如何通过彼此协调来支撑起一个灵活的界面编程接口； 其实提到元数据（Metadata）大家在研究某个应用框架的时候都曾经或多或少的见到过，可能并没有引起你的注意；其实在很多应用框架中我们都能看见Matedata的影子，它是一个很不错的框架设计模式，俗称：“元数据驱动设计”，它跟目前很多设计思想很接近，如：元编程、契约式设计，这些模式目的都是为了能很好的控制耦合，产生极大的扩展灵活性；元编程让我们能基于最终的用户选择动态的产生运行软件的代码，而契约式设计能让我们将控制权设立在很远的地方，从而很大粒度的控制扩展性，根据契约设立规则，控制端再在运行时动态的生成出最终需要的规则； 阅读全文

摘要： 在一般的函数调用情况下，我们都习惯性的将参数传入到某个被调用的方法，这可能就是我们考虑调用方法的惯用思维，但是现在的C#语言得到了很大的提升，我们可以很自然的使用委托来减少函数之间的参数依赖；有时候会经常看见一个函数的内部逻辑并没有使用到传入的某个参数，而传入的真正目的是为了再传入到本函数需要调用的另外一个函数中去； 阅读全文

摘要： 说到类型码，我们都会很有印象，在某个Entity内部多多少少会出现一两个类型码来表示当前Entity在某个抽象角度属于哪一种层面，比如在EmployeeEntity中，基本上会有一个表示性别的Age的属性，同时Age属性的最终保存是在某个age字段中的，它就是很典型的类型码元素；Age类型码属性用来表达了在用性别这一个抽象角度对实体进行分类时，那么实体会存在着两种被归纳的层面（男、女）； 在这个Age类型码属性被使用到的任何一个逻辑的地方都会有可能因为它的值不同而进行不同的逻辑分支，就好比我们在EmployeeCollectionEntity对象中定义一个方法，用来返回指定类型的所有EmployeeEntity 阅读全文

摘要： 上一篇文章“.NET/ASP.NET MVC Controller 控制器（一：深入解析控制器运行原理）”详细的讲解了MvcHandler对象内部的基本流程逻辑，这基本的流程逻辑为我们后面的学习起到铺垫作用，当我们能正确的搞懂它的内部执行流程后，我们就可以顺藤摸瓜的去挖掘每个逻辑环节中的详细逻辑； 通过前面两篇文章的介绍，我们基本上能搞清楚一个Url请求是如何借助于UrlRoutingModule模块顺利穿过ASP.NET基础框架到达应用框架的过程，当UrlRoutingModule处理过后将RouteData对象封装在RequestContext请求上下文中传入到MvcHandler对象，然后MvcHandler对象通过IControllerFactory接口根据从RouteData中获取到controllername控制器名称字符串创建具体的IController对象实例； 阅读全文

摘要： 经过前一篇文章.NET/ASP.NET Routing路由（深入解析路由系统架构原理） 的讲解，我们对ASP.NETRouting路由系统的整个运行机制有了一个基本的了解；当我们能清楚的知道Url是如何被解析成RouteData对象时，下面就是这些路由数据是如何被后面的应用框架所使用的，而通往应用框架的入口是MvcRouteHandler对象； 这篇文章将继续讲解通过路由后的ASP.NETMVC Controller控制器是如何被加载、激活并且执行的；跟控制器相关的一套对象模型是被MvcHandler对象作为源头调用起来的，也就是说，当我们穿过UrlRoutingModule对象后 阅读全文

摘要： 这篇文章让我们愉快的学习一下ASP.NET中核心的对象模型Routing模块，为什么说愉快呢，因为Routing正是建立在大家都比较熟悉的ASP.NET管道模型基础之上的，所以相比其他一些陌生的概念会轻松很多，不过不要紧一回生二回熟； ASP.NET Routing 系统是一切通过ASP.NET进行Uri访问应用程序的基础（并非物理文件的直接映射）；随着Routing的出现，我们的WEB设计已经和以前大不一样；越来越轻量级、简单化，都通过简便的Uri资源的方式进行处理，将精力放在业务的设计上；现在主流的Rest ful api 也都是建立在这样的一种机制下的，然而我们的ASP.NETMVC也是一种通过独立的Uri进行程序访问处理的框架 阅读全文

摘要： ASP.NET Routing 路由功能非常强大，设计的也很巧妙；如果说ASP.NETMVC是建立在ASP.NET之上还不如准确的说ASP.NETMVC是建立在Routing基础之上的，才使得Controller顺利被找到并且执行Action； 那么今天这篇文章是一个简短的介绍如何在ASP.NETMVC下进行很好的模块化开发，都知道ASP.NETMVC是分层架构中的UI层框架；而UI层的开发有着天生的难以控制性，尤其是WEBUI和WINFORMUI有着很大的区别；WEBUI的组成元素多，又是在远程的浏览器中处理的，所以还是很考验架构设计的； 阅读全文

摘要： 重构已是老生常谈的话题，我们或多或少对它有所了解但是对它的深刻理解恐怕需要一段实践过后才能体会到；提到重构就不得不提为它保驾护航的大功臣单元测试，重构能有今天的风光影响力完全少不了单元测试的功劳；最近一段时间写单元测试用例的时间远超过我写逻辑代码的时间和多的多的代码量，这是为什么？我一开始很难给自己一... 阅读全文

摘要： 最近这几天在捣鼓并行计算，发现还是有很多值得分享的意义，因为我们现在很多人对它的理解还是有点不准确，包括我自己也是这么觉得，所以整理一些文章分享给在使用.NET并行计算的朋友和将要使用.NET并行计算的朋友； NET并行编程推出已经有一段时间了，在一些项目代码里也时不时会看见一些眼熟的并行计算代码，作为热爱技术的我们怎能视而不见呢，于是捣鼓了一番跟自己的理解恰恰相反，看似一段能提高处理速度的并行代码为能起效果，跟直接使用手动创建的后台线程处理差不多，这不太符合我们对.NET并行的强大技术的理解，所以自己搞了点资料看看，实践了一下，发现在使用.NET 阅读全文