Fork me on GitHub
共 4 页: 上一页 1 2 3 4 下一页
摘要:随着现在的企业应用架构都在向着SOA方向转变,目的就是将一个庞大的业务系统按照业务进行划分,不管从公司的管理上、产品的开发上,这一系列流程来看,都是正确的。SOA确实带来了解决现在大型企业级应用系统快速膨胀的解决办法。 但是本文要说的是,我们都将目光转向到了后端,也就是服务端,而将精力和时间都重点投在了后端服务的架构设计上,渐渐的忽视了显示端的架构设计。然而显示端的逻辑也越来越复杂,显示端轻薄的架构其实已经浮现出难以应付后端服务接口快速膨胀的危险,服务接口都是按照指数级增加,基本上每一个新的业务需求都是提供新的接口,这没有问题。按照服务的设计原则,服务接口就应该有着明确的作用,而不是按照代码的思维来考虑接口的设计。 但是由此带来的问题就是组合这些接口的显示端的结构是否和这种变化是一致的,是否做好了这种变化带来显示端逻辑复杂的准备。 阅读全文
posted @ 2014-09-08 16:24 王清培 阅读 (7448) 评论 (34) 编辑
摘要:一直都在谈论面向对象开发,但是开发企业应用系统时,使用面向对象开发最大的问题就是在于,多个对象之间的互操作需要涉及数据库操作。两个业务逻辑对象彼此之间需要互相调用,如果之间的互相操作是在一个业务事务范围内的,很容易完成,但是如果本次业务逻辑操作涉及到多个业务对象一起协作完成时问题就来了。 在以往,我们使用过程式的代码(事务脚本模式),将所有与本次业务事务范围内相关的所有逻辑都写在一个大的代码中,就算你适当的提取重复代码,效果也不大,因为你永远都.. 阅读全文
posted @ 2014-09-01 21:07 王清培 阅读 (4319) 评论 (9) 编辑
摘要:对软件开发方法论有兴趣的博友应该发现最近“领域驱动设计”慢慢的被人发现被人实践起来,园子里也慢慢有了DDD的学习气氛和宝贵实战经验的分享。其实之前我也痴迷于DDD,为什么会痴迷于它并不是因为它是所谓的新技术,也不是因为各种对它的炒作,而是我觉得我找到了能解放我们进行企业业务系统开发的方法论。 DDD可以很好的指导我们开发可靠的软件系统,尤其是现在的企业业务复杂多变的情况下,使用DDD可以很好的随着业务变化不断的重构现有的领域模型,最为重要的是我觉得DDD是能够很好的实施敏捷价值观的软件开发方法论。 阅读全文
posted @ 2014-08-30 20:45 王清培 阅读 (3196) 评论 (26) 编辑
摘要:要想正确的设计系统架构就必须能正确的搞懂每个架构模式的用意,而不是胡子眉毛一把抓。现在有一个现象是什么呢,项目的结构从表面上看是很不错,层分的很合理,其实对业务系统来说也就那么几种层设计方法,但是现在很多项目的逻辑架构的设计不是理想,有很多概念大家并不是很了解,当然也许每个人对技术的追求不同罢了。不管你追求不追求,事实我们还是要去往正确的方向努力才对的。 阅读全文
posted @ 2014-08-25 20:58 王清培 阅读 (3308) 评论 (13) 编辑
摘要:接触分层架构有段时间了,从刚开始的朦朦胧胧的理解到现在有一定深度的研究后,觉得有必要将自己的研究成果分享出来给大家,互相学习,也是对自己的一个总结。 我们每天面对的项目结构可以说几乎都是分层结构的,或者是基于传统三层架构演变过来的类似的分层结构,少不了业务层、数据层,这两个层是比较重要的设计点,看似这两个层是互相独立的,但是这两个层如何设计真的还有很多比较微妙的地方,本文将分享给大家我在工作中包括自己的研究中得出的比较可行的设计方法。 阅读全文
posted @ 2014-08-19 21:24 王清培 阅读 (5603) 评论 (15) 编辑
摘要:至今我都清楚的记得我第一次被面试官问起什么叫”建模“技术时的情景,那是好几年前的事情了,当时是胸有成竹的去面试一个有关系统分析、设计的.NET高级软件工程师岗位。面试官几乎没问我有关.NET方面的任何技术实现,他就简单的问了问:“你如何把握你所分析出来的系统的正确性?”,我当时有点小激动,觉得这个问题应该很简单嘛,都是概念而已,让他直接点问,结果他来一句:“你懂建模吗?,能给我解释一下建模的作用吗?“,接着他出了一个小例子,让我对这个例子进行建模,要考虑到各种扩展性、业务稳定性的关键点,要边建模边说出为什么要这么建模,要说出思路。他最后重点强调了一下:“创建出来的模型是不允许跟任何具体的代码、工具有关联的”。 阅读全文
posted @ 2014-08-12 19:53 王清培 阅读 (3896) 评论 (53) 编辑
摘要:有一段时间没有更新博客了,最近半年都在着写书《.NET框架设计—大型企业级框架设计艺术》,很高兴这本书将于今年的10月份由图灵出版社出版,有关本书的具体介绍等书要出版的时候我在另写一篇文行做介绍。可以先透露一下,本书是博主多年来对应用框架学习的总结,里面包含了十几个重量级框架模式,这些模式都是我们目前所经常使用到的,对于学习框架和框架开发来说是很好的参考资料,大家敬请期待。 好了,进入文章主题。 最近几个月本人一直从事着SOA服务开发工作,简单点讲就是提供服务接口的;从提供前端接口WEBAPI,到提供后端接口WCF\SOAFramework,期间学到了不少有关多线程使用上的经验,这些经验有的是本人自己的错误使用后的经验,有些是公司的前辈的指点,总之这些东西你不遇到过你是不会意识到该如何使用的,所以本人觉得很有必要总结分享给广大和我一样工作在一线的博友们。 阅读全文
posted @ 2014-07-26 12:56 王清培 阅读 (6482) 评论 (6) 编辑
摘要:由于博主今后一段时间可能会很忙(准备出书:《.NET框架设计—模式、配置、工具》,外加换了新工作),所以博客会很少更新; 在最近一年左右时间里,博主各种.NET技术类型的文章都写过,根据博友们的反馈觉得还不错,所以应该有整理一下目录的必要,防止随着时间的推移很多现在来说还比较新的技术文章到时候就不知名的石沉大海了;整理之后更方便大家查询,阅读,谢谢; 阅读全文
posted @ 2014-03-02 12:56 王清培 阅读 (12592) 评论 (43) 编辑
摘要:DomainModel是由很多细粒度的Object组成,按照以往的教训(将Object行为、数据肢解,得到一个残缺的Object),现在我们将逻辑行为和数据绑定在一起,形成了一个丰富的领域模型,这也是面向对象设计原则之一;想了解更多关于实现面向对象的技巧请参考【《实现模式》作者:Kent Beck】一书; 但是这样又带来了由于充血型DDD模型会给面向大规模查询的业务模块带来一定的性能开销,试想一个OrderManager对象,如果我们需要获取在某个条件范围类的所有Order会给OrderManager带来很多性能、逻辑上的复杂度;根据DDD.CQRS架构,得知将DomainModel中的查询逻辑单独剥离出去,让Command端很干净的处理聚合的写逻辑,在Query端也很直接的处理查询逻辑; 阅读全文
posted @ 2014-02-16 12:04 王清培 阅读 (4292) 评论 (6) 编辑
摘要:现在越来越多的公司都在尝试SOA架构的实践,本人最近也在尝试学习这方面的技术,但是在实践过程中遇到一个问题,我想这个问题也是我们普遍实践者都应该会遇到的问题,问题描述如下: 我们有一个SOA商品(Item)查询接口,这个接口很通用,主要用来支撑日常很多其他系统的大量关于Item的查询,尤其是在高峰期间该服务的压力是很大的;我们站在SOA的角度看这个接口,这个通用的接口解决了众多的查询业务,确实不错,但是我们切换一下角度,站在每一个调用接口的访问端看似乎并不是很满意或者说牺牲了部分性能上的代价,因为我们无法干净利落的只获取当前这个业务点需要的数据项;这个Item服务接口所返回的数据项必须同时满足所有调用它的业务点,哪怕这次调用我只需要用到Item的三分之一的数据字段都不行,每次都会把不需要的字段都查询出来,不管是返回的性能、查询的性能,其实都是可以通过调整设计来避免的; 阅读全文
posted @ 2014-02-06 18:47 王清培 阅读 (4686) 评论 (16) 编辑
摘要:使用ASP.NETMVC构建普通的中小型站点可以使用简单的Model元数据设置方式来控制ViewModel如何显示在View中,但是复杂的应用场景不会这么简单的就能完成;大型站点的ViewModel的体积非常大,真的大的超乎我们的想象(当然这里面有历史原因),这么大的一个显示实体我们需要在不同的页面中呈现它会非常的棘手;然而小型站点不太会遇见ViewModel在几十个页面中显示的情况出现,一般页面也就是几十个差不多了; 在大型电子商务应用中,UI层的一个ViewModel不仅用来呈现数据还充当着与远程SOA接口通讯的DTO作用,如果为了结构清晰完全可以将ViewModel与DTO分开,但是有时候我们确实需要考虑额外的性能开销(有时候我们只能接受历史遗留的问题,技术债务累积多久就要还多久); 阅读全文
posted @ 2014-01-20 14:00 王清培 阅读 (3015) 评论 (4) 编辑
摘要:在View中用来根据当前View中引入的强类型ViewModel生成HTMLDom结构的核心功能都被封装在以HtmlHelper为首的对象模型中,包括HtmlHelper泛型类型,它直接派生自HtmlHelper基类,这两个类型的功能都是围绕着如何生成前端所需要的HTML结构和一些常用的UI元素; 但是这两个类型所能做的事情很有限,它们只是庞大生成功能的核心模型;我们使用的都是围绕着这两个类型的扩展方法,如: @Html.EditorForModel() 在当前View中引用的Html属性其实是一个HtmlHelper类型的属性,定义代码: public HtmlHelper Html { get; set; } 该类型被定义在public abstract class WebViewPage : WebViewPage类 阅读全文
posted @ 2014-01-13 11:58 王清培 阅读 (2850) 评论 (8) 编辑
摘要:ModelMetadata是ASP.NETMVC中用来表示Model的元数据对象,它包含了一个Model的所有的相关元数据信息,当然这取决Model的使用方向,不同的使用方向会有不同类型的元数据,我们这里的ModelMetadata是针对View显示相关的元数据;ModelMetadata中绝大部分元数据是用来作为最终在View生成环节当中需要使用到的,比如:如何确定一个领域相关的属性(Address)该如何展现,这里的Address可能不是一个简单的String类型表示,而是由一组复杂的类型表示,这样的情况下我们就需要通过自定义元数据来控制最终使用的呈现模板(PartialView); 在MVC的定义中,Model准确意思是ViewModel(显示Model,只是用来作为界面呈现使用的数据实体),它是直接提供给View作为呈现使用的数据实体,通常情况下还将作为DTO类型的数据实体,负责数 阅读全文
posted @ 2013-12-16 15:22 王清培 阅读 (3088) 评论 (5) 编辑
摘要:这篇文章让我们一起来学习一下有关Asp.netMvc中的Mode元数据的相关设计和围绕元数据的一些其他对象模型,他们是如何通过彼此协调来支撑起一个灵活的界面编程接口; 其实提到元数据(Metadata)大家在研究某个应用框架的时候都曾经或多或少的见到过,可能并没有引起你的注意;其实在很多应用框架中我们都能看见Matedata的影子,它是一个很不错的框架设计模式,俗称:“元数据驱动设计”,它跟目前很多设计思想很接近,如:元编程、契约式设计,这些模式目的都是为了能很好的控制耦合,产生极大的扩展灵活性;元编程让我们能基于最终的用户选择动态的产生运行软件的代码,而契约式设计能让我们将控制权设立在很远的地方,从而很大粒度的控制扩展性,根据契约设立规则,控制端再在运行时动态的生成出最终需要的规则; 阅读全文
posted @ 2013-12-02 13:38 王清培 阅读 (3038) 评论 (10) 编辑
摘要:在一般的函数调用情况下,我们都习惯性的将参数传入到某个被调用的方法,这可能就是我们考虑调用方法的惯用思维,但是现在的C#语言得到了很大的提升,我们可以很自然的使用委托来减少函数之间的参数依赖;有时候会经常看见一个函数的内部逻辑并没有使用到传入的某个参数,而传入的真正目的是为了再传入到本函数需要调用的另外一个函数中去; 阅读全文
posted @ 2013-11-20 20:18 王清培 阅读 (2294) 评论 (2) 编辑
摘要:说到类型码,我们都会很有印象,在某个Entity内部多多少少会出现一两个类型码来表示当前Entity在某个抽象角度属于哪一种层面,比如在EmployeeEntity中,基本上会有一个表示性别的Age的属性,同时Age属性的最终保存是在某个age字段中的,它就是很典型的类型码元素;Age类型码属性用来表达了在用性别这一个抽象角度对实体进行分类时,那么实体会存在着两种被归纳的层面(男、女); 在这个Age类型码属性被使用到的任何一个逻辑的地方都会有可能因为它的值不同而进行不同的逻辑分支,就好比我们在EmployeeCollectionEntity对象中定义一个方法,用来返回指定类型的所有EmployeeEntity 阅读全文
posted @ 2013-11-18 14:06 王清培 阅读 (6127) 评论 (32) 编辑
摘要:上一篇文章“.NET/ASP.NET MVC Controller 控制器(一:深入解析控制器运行原理)”详细的讲解了MvcHandler对象内部的基本流程逻辑,这基本的流程逻辑为我们后面的学习起到铺垫作用,当我们能正确的搞懂它的内部执行流程后,我们就可以顺藤摸瓜的去挖掘每个逻辑环节中的详细逻辑; 通过前面两篇文章的介绍,我们基本上能搞清楚一个Url请求是如何借助于UrlRoutingModule模块顺利穿过ASP.NET基础框架到达应用框架的过程,当UrlRoutingModule处理过后将RouteData对象封装在RequestContext请求上下文中传入到MvcHandler对象,然后MvcHandler对象通过IControllerFactory接口根据从RouteData中获取到controllername控制器名称字符串创建具体的IController对象实例; 阅读全文
posted @ 2013-11-14 20:31 王清培 阅读 (6035) 评论 (4) 编辑
摘要:经过前一篇文章.NET/ASP.NET Routing路由(深入解析路由系统架构原理) 的讲解,我们对ASP.NETRouting路由系统的整个运行机制有了一个基本的了解;当我们能清楚的知道Url是如何被解析成RouteData对象时,下面就是这些路由数据是如何被后面的应用框架所使用的,而通往应用框架的入口是MvcRouteHandler对象; 这篇文章将继续讲解通过路由后的ASP.NETMVC Controller控制器是如何被加载、激活并且执行的;跟控制器相关的一套对象模型是被MvcHandler对象作为源头调用起来的,也就是说,当我们穿过UrlRoutingModule对象后 阅读全文
posted @ 2013-10-27 14:01 王清培 阅读 (21677) 评论 (11) 编辑
摘要:这篇文章让我们愉快的学习一下ASP.NET中核心的对象模型Routing模块,为什么说愉快呢,因为Routing正是建立在大家都比较熟悉的ASP.NET管道模型基础之上的,所以相比其他一些陌生的概念会轻松很多,不过不要紧一回生二回熟; ASP.NET Routing 系统是一切通过ASP.NET进行Uri访问应用程序的基础(并非物理文件的直接映射);随着Routing的出现,我们的WEB设计已经和以前大不一样;越来越轻量级、简单化,都通过简便的Uri资源的方式进行处理,将精力放在业务的设计上;现在主流的Rest ful api 也都是建立在这样的一种机制下的,然而我们的ASP.NETMVC也是一种通过独立的Uri进行程序访问处理的框架 阅读全文
posted @ 2013-10-20 15:27 王清培 阅读 (21818) 评论 (25) 编辑
摘要:ASP.NET Routing 路由功能非常强大,设计的也很巧妙;如果说ASP.NETMVC是建立在ASP.NET之上还不如准确的说ASP.NETMVC是建立在Routing基础之上的,才使得Controller顺利被找到并且执行Action; 那么今天这篇文章是一个简短的介绍如何在ASP.NETMVC下进行很好的模块化开发,都知道ASP.NETMVC是分层架构中的UI层框架;而UI层的开发有着天生的难以控制性,尤其是WEBUI和WINFORMUI有着很大的区别;WEBUI的组成元素多,又是在远程的浏览器中处理的,所以还是很考验架构设计的; 阅读全文
posted @ 2013-10-14 12:26 王清培 阅读 (12331) 评论 (23) 编辑
摘要:重构已是老生常谈的话题,我们或多或少对它有所了解但是对它的深刻理解恐怕需要一段实践过后才能体会到;提到重构就不得不提为它保驾护航的大功臣单元测试,重构能有今天的风光影响力完全少不了单元测试的功劳;最近一段时间写单元测试用例的时间远超过我写逻辑代码的时间和多的多的代码量,这是为什么?我一开始很难给自己一... 阅读全文
posted @ 2013-10-06 19:45 王清培 阅读 (3097) 评论 (12) 编辑
摘要:最近这几天在捣鼓并行计算,发现还是有很多值得分享的意义,因为我们现在很多人对它的理解还是有点不准确,包括我自己也是这么觉得,所以整理一些文章分享给在使用.NET并行计算的朋友和将要使用.NET并行计算的朋友; NET并行编程推出已经有一段时间了,在一些项目代码里也时不时会看见一些眼熟的并行计算代码,作为热爱技术的我们怎能视而不见呢,于是捣鼓了一番跟自己的理解恰恰相反,看似一段能提高处理速度的并行代码为能起效果,跟直接使用手动创建的后台线程处理差不多,这不太符合我们对.NET并行的强大技术的理解,所以自己搞了点资料看看,实践了一下,发现在使用.NET 阅读全文
posted @ 2013-09-22 12:37 王清培 阅读 (4401) 评论 (10) 编辑
摘要:这篇文章将简单的分析一下有关静态文件捆绑的ASP.NET组件System.Web.Optimization的运行原理及基本的缓存问题; 在我们的项目里面充斥着很多静态文件,为了追求模块化、插件化很多静态文件都被设计成模块的方式或者被分解,在需要的时候在通过组合的方式在UI层上使用;这就带来一个问题,文件多了会影响浏览器加载页面的速度,而且由于浏览器的并发限制,对于并行.... 阅读全文
posted @ 2013-09-09 14:32 王清培 阅读 (5201) 评论 (25) 编辑
摘要:最近一段时间结束了一个小项目的开发,觉得有些好东西值得总结与分享,所以花点时间整理成文章; 大多数情况下我们都知道这些概念,面向接口编程是老生常谈的话题了,有几年编程经验的都知道怎么运用;单元测试其实在前几年不怎么被重视,然而最近逐渐的浮现在我们眼前,而且被提起的频率也大了很多了,包括重构、可测试性都慢慢的贴近我们,我们只有亲自动手去使用它才能领悟其精髓; 阅读全文
posted @ 2013-08-25 13:06 王清培 阅读 (4495) 评论 (12) 编辑
摘要:本来这篇文章是“[置顶].NET领域驱动设计—实践(穿过迷雾走向光明)”一文的一部分但是由于时间关系,完整的示例并没有跟文章同步发布,说实话时间太紧,写示例的目的是想全面的且细致的阐述DDD的分析、设计各个环节的最佳实践;原本想将文章的示例做好后在发布,但是由于工作关系和一些私人原因可能有一段时间不更新博客,又不想这篇文章拖的太久,所以我总结了两点比较有价值的地方分享给大家,目的不是让大家能会使用DDD来设计系统,而是能有一个突破点来衡量DDD到底比传统三层好在哪里,因为大部分人还没有DDD的开发经验所以能体会到应该没有相关途径; 阅读全文
posted @ 2013-08-18 16:27 王清培 阅读 (18010) 评论 (31) 编辑
摘要:这一篇文章我早准备写的,迟迟未写的原因是它过于抽象不太容易表达,也很难掌握;之前对它的理解还处于比较简单的功能性上,但是最近随着对领域驱动设计及架构的研究,设计思想有了一个提升对它的理解也有了一个更清晰的轮廓,所以才敢下手去写,这么好的一篇文章不能搞砸了; “钝化语句” 简单描述:将基于栈的调用抽象成基于我们自己构建的虚拟运行时调用; 阅读全文
posted @ 2013-08-11 16:51 王清培 阅读 (4699) 评论 (16) 编辑
摘要:通过上一篇的“.NET框架设计—常被忽视的C#设计技巧”一文来看,对于框架设计的技巧还是有很多人比较有兴趣的,那么框架设计思想对于我们日常开发来说其实并不是很重要,但是对于我们理解框架背后的运行原理至关重要;当我们使用着LINQ灵活的语法的同时我们是否能理解它的背后运行原理、设计原理更深一点就是它的设计模式及复杂的对象模型; 从一开始学习.NET我就比较喜欢框架背后的设计模型,框架提供给我们的使用接口是及其简单的,单纯从使用上来看我们不会随着对框架的使用时间而增加我们对框架内部设计的理解,反而会养成一样拿来即用的习惯,我们只有去了解、深挖它的内部设计原理才是我们长久学习的目标;因为框架的内部设计模式是可以提炼出来并被总结的; 这篇文章总结了几个我最近接触的框架设计思想,可以称他们为模式;由于时间关系,这里只是介绍加一个简单的介绍和示例让我们能基本的了解它并且能在日后设计框架 阅读全文
posted @ 2013-08-04 19:07 王清培 阅读 (13169) 评论 (20) 编辑
摘要:本文中的内容都是我无意中发现觉得有必要分享一下的设计经验,没有什么高深的技术,只是平时我们可能会忽视的一些设计技巧;为什么有这种想法是因为之前跟一些同事交流技术的时候会发现很多设计思维被固化了,比如之前我在做客户端框架开发的时候会去设计一些关于Validator、DTO Transfer等常用的Common function,但是发现在讨论某一些技术实现的时候会被弄的云里雾里的,会自我郁闷半天,不会及时的明白对方在说的问题; 后来发现他们一是没有把概念分清楚,比如.NETFramework、C#、VisualStudio,这三者之间的关系;二是没有理解.NET中各个对象的本质含义,比如这里的特性(Attribute),大部分人都认为 阅读全文
posted @ 2013-07-29 16:26 王清培 阅读 (36788) 评论 (114) 编辑
摘要:在开始这篇富有某种奇妙感觉的文章之旅时我们先短暂的讨论一下关于软件开发方法论的简要: 纵观软件开发方法论,从瀑布模型、螺旋模型、RUP(统一软件开发过程)、XP(极限编程)、Agile(敏捷开发)一路走来,他们的好他们的美,我想接触过的人都会口口称赞,都是大师们一身的经验结晶最后沉淀为专业的技术方向、技术领域,带领我们软件开发者们永无止境的前进,目睹一场又一场的美景一桌又一桌盛宴。他们在不断的开辟新的领域,称为伟大的科学家一点都不为过。 阅读全文
posted @ 2013-06-30 22:19 王清培 阅读 (15816) 评论 (50) 编辑
摘要:原则对于任何一项技术实现来说都是至关重要的,在设计某一个系统功能的时候我们讲究的是设计原则: 【单一职责原则Single Responsibility Principle、里氏替换原则Liskov Substitution Principle、依赖倒置原则Dependence Inversion Principle、接口隔离原则Interface Segregation Principle、迪米特法则Law Of Demeter、开闭原则Open Close Principle】。 在架构设计的时候我们也讲究架构原则: 阅读全文
posted @ 2013-04-10 16:22 王清培 阅读 (8971) 评论 (8) 编辑
摘要:最近在研究DDD颇有收获,所以整理出来跟大家分享,共同进步! 我们在设计业务系统的时候都会存在一个非常棘手而又无法回避的问题“业务扩展性”、“业务灵活性、”面向对象化“,尽管我们熟练掌握设计思想、设计模式、设计原则等等关于如何设计灵活性的系统设计理论,但是我们似乎都没有将它们运用到真正业务系统设计、开发当中去,为什么?这样的疑问如果对有心想设计好系统的朋友来说肯定是很早就出现过,只是无法解决,因为我们目前使用的设计方法是与面向对象设计背道而驰的。 阅读全文
posted @ 2013-04-07 19:28 王清培 阅读 (14236) 评论 (44) 编辑
摘要:在看本篇文章之前我假设您已经具备我之前分析的一些原理知识,因为这章所要讲的内容是建立在之前的一系列知识点之上的,为了保证您的阅读顺利建议您先阅读本人的LINQ系列文章的前几篇或者您已经具备比较深入的LINQ原理知识体系,防止耽误您的宝贵时间。 到目前为止我们对LINQ的执行原理已经很清楚了,从它的前期构想到它真正为我们所用都有足够的证据,但是似乎问题并没有我们想的那么简单,问题总是在我们使用中频频出现尤其是新技术的使用,当然有问题才能有进步。 阅读全文
posted @ 2013-02-05 16:06 王清培 阅读 (7146) 评论 (18) 编辑
摘要:#2013微软MVP社区巡讲#欢迎热爱微软技术的开发人员和IT专业人士参与“新年新期待”2013微软MVP新年社区巡讲。微软最有价值专家MVP将在2013年伊始到访美丽上青岛,帝都北京,泉城济南。微软专家,明星讲师为您倾情奉献Windows 8, Windows Phone, New Office技术课程,参与活动您将会与专家们进行面对面的交流。一个下午的时间轻松掌握技术握住新年礼物。 阅读全文
posted @ 2012-12-28 09:43 王清培 阅读 (1155) 评论 (2) 编辑
摘要:这个主题扯的可能有点远,但是它关系着整个LINQ框架的设计结构,至少在我还没有搞懂LINQ的本意之前,在我脑海里一直频频出现这样的模型,这些模型帮助我理解LINQ的设计原理。其实在最早接触环路模型和碎片化模型是在前两个月,那个时候有幸接触企业应用架构方面的知识,里面就有很多业务碎片化的设计技巧。其实理解这些所谓的设计模型后将大大开阔我们的眼界,毕竟研究框架是要研究它的设计原理,它的存在必然是为了解决某一类问题,问题驱动它的设计模型。所以我们在研究这样的模型的时候其实已经在不知不觉的理解问题的本质。 阅读全文
posted @ 2012-12-14 10:10 王清培 阅读 (5193) 评论 (16) 编辑
摘要:在开始看本篇文章之前先允许我打断一下各位的兴致。其实这篇文章本来是没有打算加“开篇介绍”这一小节的,后来想想还是有必要反馈一下读者的意见。经过前三篇文章的详细讲解,我们基本上对LINQ框架的构成原理有了一个根本的认识,包括对它的设计模型、对象的模型等,知道LINQ的查询表达式其实是C#之上的语法糖,不过这个糖确实不错,很方便很及时,又对一系列的LINQ支撑原理进行了大片理论的介绍,不知道效果如何; 阅读全文
posted @ 2012-12-11 20:34 王清培 阅读 (13676) 评论 (19) 编辑
摘要:什么是动态LINQ查询?LINQ的编写是静态的,因为C#是基于静态类型系统原理设计的,在编写时已经确定类型,也就是在编译时就已经知道将要执行什么样的查询,条件是什么、排序方式是什么等等。那么很大一部分应用场合中我们需要根据用户的选择来查询数据源,以往我们都是通过判断的方式来拼接查询的SQL字符串,但是现在我们面对是强类型的LINQ查询,是否可以很方便的进行类似查询。其实也没有什么好神秘的,基本的实现原理是通过动态的构建表达式树来实现IQueryable接口的查询。 阅读全文
posted @ 2012-12-04 13:05 王清培 阅读 (7824) 评论 (22) 编辑
摘要:到了这里我们似乎隐隐约约的能看见LINQ的原理,它不是空中花园,它是有基础的。在上面的一系列新特性的支持下,微软通过大面积的构建扩展方法使得上述特性能连贯的互相作用,形成自然的集成查询框架。上面的这些特性都属于语言为了LINQ而做的增强,也可以说是设计者们在不断的探索新的比较符合现代开发体系的语言特性,也越来越多的支持函数式的编程特性,比如DLR的引入对Python、Ruby函数式脚本语言的强大支持,后面也会越来越多的支持其他的函数式脚本语 阅读全文
posted @ 2012-11-22 21:42 王清培 阅读 (8368) 评论 (19) 编辑
摘要:LINQ简称语言集成查询,设计的目的是为了解决在.NET平台上进行统一的数据查询。 微软最初的设计目的是为了解决对象/关系映射的解决方案,通过简单的使用类似T-SQL的语法进行数据实体的查询和操作。不过好的东西最终都能良性的发展演化,变成了如今.NET平台上强大的统一数据源查询接口。 我们可以使用LINQ查询内存中的对象(LINQ to Object)、数据库(LINQ to SQL)、XML文档(LINQ to XML),还有更多的自定义数据源。 阅读全文
posted @ 2012-11-10 17:06 王清培 阅读 (16031) 评论 (34) 编辑
摘要:其实我本不打算写这篇文章的,但是似乎心里还是有些话要和同志们说的。 早在2011年四月份我就写过一篇“从一个职校走出来的高级程序员”文章。这篇文章是写了我从初中毕业后进入一个普通的大专职校的过程。那么今天为什么要写这篇文章呢?其实是想让和我一样的朋友能够树立起真确的心态,积极乐观的面对人生同时不要缺乏前进的动力和对美好生活憧憬的激情,职校生也能够走出精彩的人生! 很高兴在十一长假期间收到微软最有价值专家的通过邮件,我想这份大礼足以让我的国庆假日开心圆满结束。我是申请了2012年度10月份的Visual C#方向的Microsoft MVP,其实也是我去年立下的一个目标,很高兴现在实现了,心中有点感慨与正在努力的同志们分享一下。[王清培版权所有,转载请给出署名] 阅读全文
posted @ 2012-10-07 13:40 王清培 阅读 (11080) 评论 (89) 编辑
摘要:在很久很久以前我们的祖先将我们大自然所有能动的物体都定义成“动物”。但是后来在动物的群体当中,有一类动物进化的非常快,它们的智商明显高出其他动物,它们就是“人类”,这也许就是人类文明的起源。 所谓的“人类”开始给动物定义级别了,他们认为“人类”是最聪明的,从而将自己和普通的动物划分界限并且人类是主导“动物”世界的头领。[王清培版权所有,转载请给出署名] 可是大自然总是充满杀戮,大鱼吃小鱼,小鱼吃虾米。这个时候有个很聪明的“人类”动物他想统治全世界,他想来想去如何对这些动物进行管理,怎么让他们能服从于我。所以他进行策划,想法设法的对这些动物进行分析,观察他们的生活习惯,主动的去跟他们交流。他认为不管是什么动物都将有着本质的特性,这些特性是生命的延续也是动物特征的延续。时间不知道过去了多少,他终于总结出一个让一般动物都很难理解的“抽象”动物图。 阅读全文
posted @ 2012-08-11 21:24 王清培 阅读 (2674) 评论 (7) 编辑
共 4 页: 上一页 1 2 3 4 下一页