yangyang

a .NET Developer

Design Patterns


如何正确对外暴露集合对象

我们在定义一个实体的时候,一般是不希望对外暴露其内部过多的成员信息的。尤其是一些集合信息,因为这些集合信息如果对外暴露不慎,就会破坏封装性,从而使得外部对象能够对其进行一些破坏性的修改。所以对外我们一般返回只读集合,这个问题在之前的文章不要对外公开泛型List成员中提到过。 问题的产生 下面以我们购物中的购物车为例来说明: public class Cart { private List<ProducItem> ProductItemsCollection; public Cart() { ProductItemsCollection = new List<ProducItem>(); } /// < …

IReadOnlyCollection

推荐文章

写了一些文章,有一些自己比较满意,这些都是以系列的方式写的;还有一些写的比较随意,有凑数的嫌疑😂 (就像现在很多智能手机有很多摄像头一样,凑数的四摄🤣),这里列出自己相对比较满意的文章,方便查看。 1.Excel开发系列 这个是我当年在某财经公司做Office插件开发时的一些新得和总结,毫不谦虚的说,大概是目前网上关于Office插件开发比较全的文章,这方面资料比较少,这些文章是在工作中跟同事以及在网上不断查找探索的总结。总共写了十一篇。 浅谈Excel开发:一 Excel 开发概述 浅谈Excel开发:二 Excel 菜单系统 浅谈Excel开发:三 Excel 对象模型 浅谈Excel开发:四 Excel 自定义函数 浅谈Excel开发:五 Excel RTD函数 浅谈Excel开发:六 Excel 异步自定义函数 浅谈Excel开发: …

Excel Development Design Pattern SQLServer Performance Optimizing Data Structure Algorithm

浅谈依赖注入

最近几天在看一本名为Dependency Injection in .NET 的书,主要讲了什么是依赖注入,使用依赖注入的优点,以及.NET平台上依赖注入的各种框架和用法。在这本书的开头,讲述了软件工程中的一个重要的理念就是关注分离(Separation of concern, SoC)。依赖注入不是目的,它是一系列工具和手段,最终的目的是帮助我们开发出松散耦合(loose coupled)、可维护、可测试的代码和程序。这条原则的做法是大家熟知的面向接口,或者说是面向抽象编程。 关于什么是依赖注入,在Stack Overflow上面有一个问题,如何向一个5岁的小孩解释依赖注入,其中得分最高的一个答案是: “When you go and get things out of the refrigerator for yourself, you can cause …

Dependency Injection .NET

浅谈WebService的版本兼容性设计

在现在大型的项目或者软件开发中,一般都会有很多种终端, PC端比如Winform、WebForm,移动端,比如各种Native客户端(iOS, Android, WP),Html5等,我们要满足以上所有这些客户端的需求,实现前后端的分离,一种最常见的做法是,编写WebService API来为以上客户端提供数据。近年来越来越多的企业或者网站支持Restfull方式的WebService,比如当当网开源Dubbox,扩展Dubbo服务框架支持REST风格远程调用,这个是Java版本的,在.NET中ServiceStack天生支持Restfull风格的WebService。本文主要以ServiceStack为基础探讨,浅谈API的兼容性设计。 1.软件的兼容性 在软件持续更新升级的过程中,API 也是需要不断更新,这时就需要考虑客户端升级以及兼容性的问题。当前有很多用户可能由于多种原因,尤 …

WebService Backward Compatibility Message base design .NET

浅谈命令查询职责分离(CQRS)模式

在常用的三层架构中,通常都是通过数据访问层来修改或者查询数据,一般修改和查询使用的是相同的实体。在一些业务逻辑简单的系统中可能没有什么问题,但是随着系统逻辑变得复杂,用户增多,这种设计就会出现一些性能问题。虽然在DB上可以做一些读写分离的设计,但在业务上如果在读写方面混合在一起的话,仍然会出现一些问题。 本文介绍了命令查询职责分离模式(Command Query Responsibility Segregation,CQRS),该模式从业务上分离修改 (Command,增,删,改,会对系统状态进行修改)和查询(Query,查,不会对系统状态进行修改)的行为。从而使得逻辑更加清晰,便于对不同部分进行针对性的优化。文章首先简要介绍了传统的CRUD方式存在的问题,接着介绍了CQRS模式,最后以一个简单的在线日记系统演示了如何实现CQRS模式。要谈到读写操作,首先我们来看传统的CRUD的问题。 …

CQRS .NET DDD

熔断器设计模式

如果大家有印象的话,尤其是夏天,如果家里用电负载过大,比如开了很多家用电器,就会”自动跳闸”,此时电路就会断开。在以前更古老的一种方式是”保险丝”,当负载过大,或者电路发生故障或异常时,电流会不断升高,为防止升高的电流有可能损坏电路中的某些重要器件或贵重器件,烧毁电路甚至造成火灾。保险丝会在电流异常升高到一定的高度和热度的时候,自身熔断切断电流,从而起到保护电路安全运行的作用。 同样,在大型的软件系统中,如果调用的远程服务或者资源由于某种原因无法使用时,如果没有这种过载保护,就会导致请求的资源阻塞在服务器上等待从而耗尽系统或者服务器资源。很多时候刚开始可能只是系统出现了局部的、小规模的故障,然而由于种种原因,故障影响的范围越来越大,最终导致了全局性的后果。软件系统中的这种过载保护就是本文将要谈到的熔断器模式(Circuit Breaker) …

Circuit Breaker .NET Design Pattern

不要对外公开泛型List成员

最近在阅读Framework Design Guidelines,本着现学现用的原则,于是就用FxCop工具对代码进行规范性检查时,发现了很多问题,其中包括命名以及一些设计上的规范。 其中,Do not expose generic lists 这条设计规范引起了我的注意。该规范指出“不要在对象模型中对外暴露List<T>,应该考虑使用Collection<T>,ReadOnlyCollection<T>或者KeyedCollection<K,V>,List<T>是原先ArrayList的泛型实现,是最基础的、性能最好和功能最强大的“动态数组”,对性能进行了优化,但是相对较“封闭”,入口较多。比如,如果奖List<T>对象返回给客户端,那么就不能实现诸如 …

List Collection

从Undo,Redo谈命令模式

一般的应用软件中,通常会提供Redo和Undo的操作,比如Paint.NET中的动作面板,Word中的撤销重做,一般我们按Ctrl-Z即可回退到上次操作。 要实现上面的这一功能,最直观的想法就是,我们需要把执行的命令以及相应的参数记录下来,一个命令或者动作,我们可以想象成一个对象,将这些的命令以对象的方式放到一个Stack里面,然后Undo的时候,Pop出来,然后执行该命令即可返回之前的状态。 将命令或者操作抽象为一个对象,使得可以用不同的请求参数对对象进行初始化,使得可以对命令进行排队处理,记录请求,以及执行Undo和Redo操作,这就是命令模式(Command Pattern),命令模式最大的优点就是,他将对象方法的调用和实现分离开。 为了说明如何实现Undo和Redo,我们尝试做一个简单的文本格式化的小工具,就是能够进行加粗,倾斜,加下划线,然后支持重做和撤销操作。 首 …

Command Pattern .NET

从循环引用谈依赖倒置原则

在业务开发中,通常会按照业务或者逻辑将项目分成好几个工程文件以方便重用和模块化,有时候我们分开的两个项目可能存在相互引用的情况,举个例子,比如有两个系统,订单系统和产品系统,订单系统需要从产品系统中了解当前产品是否有剩余。产品系统需要从订单系统中了解产品的销售情况,这时候就存在相互引用的情况。 循环引用在Visual Studio中是编译不通过的。出现循环引用很可能是设计上抽象不够导致的,根据设计模式的依赖倒置-高层模块不应该依赖于低层模块。二者都应该依赖于抽象,抽象不应该依赖于细节,细节应该依赖于抽象这一原则,可以来解决循环引用。 在一些项目中,使用一些依赖注入的框架如SPRING.net,CASTLE可以在一定程度上避免循环引用。 Class A中用到了Class B的对象b,一般情况下,需要在A的代码中显式的new一个B的对象。采用依赖注入技术之后,A的代码只需 …


浅谈模板方法模式

在很多时候,我们在写代码的时候总是会遇到一些相同或者类似的处理流程和步骤,就拿一般的函数编写来说,在处理之前一般会进行参数有效性验证,然后可能会对参数进行预处理,最后在执行业务操作。 这种情况通常会出现在一类业务,比如订单处理系统中,就有订单创建,订单修改等操作,就会出现的这些类似的情况。 如果每个都这样写的话,会发现整个流程比较重复和冗余。比如: class SomeProcessService { ResponseBody SomeProcess (RequestBody request) { ValidateParameter(); PreprocessingParameter(); DoSomething(); } } class …

template method