.NET系列文章——近一年文章分类整理,方便各位博友们查询学习
摘要:由于博主今后一段时间可能会很忙(准备出书:《.NET框架设计—模式、配置、工具》,外加换了新工作),所以博客会很少更新; 在最近一年左右时间里,博主各种.NET技术类型的文章都写过,根据博友们的反馈觉得还不错,所以应该有整理一下目录的必要,防止随着时间的推移很多现在来说还比较新的技术文章到时候就不知名的石沉大海了;整理之后更方便大家查询,阅读,谢谢;阅读全文
posted @ 2014-03-02 12:56 王清培 阅读(11760) 评论(43)编辑
.NET应用架构设计—面向查询的领域驱动设计实践(调整传统三层架构,外加维护型的业务开关)
摘要:DomainModel是由很多细粒度的Object组成,按照以往的教训(将Object行为、数据肢解,得到一个残缺的Object),现在我们将逻辑行为和数据绑定在一起,形成了一个丰富的领域模型,这也是面向对象设计原则之一;想了解更多关于实现面向对象的技巧请参考【《实现模式》作者:Kent Beck】一书; 但是这样又带来了由于充血型DDD模型会给面向大规模查询的业务模块带来一定的性能开销,试想一个OrderManager对象,如果我们需要获取在某个条件范围类的所有Order会给OrderManager带来很多性能、逻辑上的复杂度;根据DDD.CQRS架构,得知将DomainModel中的查询逻辑单独剥离出去,让Command端很干净的处理聚合的写逻辑,在Query端也很直接的处理查询逻辑;阅读全文
posted @ 2014-02-16 12:04 王清培 阅读(3932) 评论(6)编辑
.NET应用架构设计—面向查询服务的参数化查询设计(分解业务点,单独配置各自的数据查询契约)
摘要:现在越来越多的公司都在尝试SOA架构的实践,本人最近也在尝试学习这方面的技术,但是在实践过程中遇到一个问题,我想这个问题也是我们普遍实践者都应该会遇到的问题,问题描述如下: 我们有一个SOA商品(Item)查询接口,这个接口很通用,主要用来支撑日常很多其他系统的大量关于Item的查询,尤其是在高峰期间该服务的压力是很大的;我们站在SOA的角度看这个接口,这个通用的接口解决了众多的查询业务,确实不错,但是我们切换一下角度,站在每一个调用接口的访问端看似乎并不是很满意或者说牺牲了部分性能上的代价,因为我们无法干净利落的只获取当前这个业务点需要的数据项;这个Item服务接口所返回的数据项必须同时满足所有调用它的业务点,哪怕这次调用我只需要用到Item的三分之一的数据字段都不行,每次都会把不需要的字段都查询出来,不管是返回的性能、查询的性能,其实都是可以通过调整设计来避免的;阅读全文
posted @ 2014-02-06 18:47 王清培 阅读(4243) 评论(16)编辑
来源: http://www.cnblogs.com/wangiqngpei557/