单例模式（Singleton)，故名思议就是说在整个应用程序中，某一对象的实例只应该存在一个。比如，一个类加载数据库中的数据到内存中以提供只读数据，这就很适合使用单例模式，因为没有必要在内存中加载多份相同的数据，另外，有些情况下不允许内存中存在多分份相同的数据，比如数据过大，内存容不下两份相同数据等等。 约定单例模式（Singleton by Convention） 这种方式有点“Too simple, Sometimes naïve”，他就是提示使用者，我是单例，不要重复初始化我，比如： public class Database { /// <summary> /// 警告，这是单例，不要初始化多次，否则，后果自负. /// </summary> public …
Prototype模式为创建型模式，翻译为原型模式。这种模式在生活中随处可见，很多产品设计一般都不会从头开始，都是从上一个版本直接不停的迭代，比如手机界早前的诺基亚“科技以换壳为本”，以及汽车工业界的更新，一般是过一年一个小改版基本就是“facelift”，然后才是大换代。 在软件工程中亦是如此，在有些情况下，与其从头开始创建一个对象（比如工厂方法模式或者生成器模式做的那样），可以从之前预构造的对象或者直接拷贝原有对象，或者对原有对象简单修改来生成新的对象。 这就产生了原型模式的概念，通过对某个对象的拷贝，定制化从而得到新的对象，原型模式的核心是拷贝，这也是容易出现问题的地方。 深拷贝与浅拷贝 拷贝分为深拷贝（Deep copy）和浅拷贝（Shallow copy)之分，区分两者至关重要。下面来看例子，我们定 …
Builder模式是创建型模式，它用来构建比较复杂的对象，这些对象无法通过单一的构造函数来实现，比如要构造一个类似HTML这样的具有嵌套结构的对象，这个类或许由其他几个类或者对象构成，或者具有一些特殊的构建逻辑。 Builder这里翻译参照GoF翻译为生成器模式，通常用来建造复杂的对象，下面用几个例子来说明，这些例子只是用来说明生成器模式，在实际应用中还要考虑其他因素。 场景 假设我们需要构建一个组件用来显示web页面。一个Web页面可能包含一个或者多个段落，或者其他组件，要构建一个段落，通常可以简单用字符串拼接，比如下面这个代码就构建了一个p段落。 var hello = "hello"; var sb = new StringBuilder(); sb.Append("<p>"); sb.Append(hello); sb. …
我们在定义一个实体的时候，一般是不希望对外暴露其内部过多的成员信息的。尤其是一些集合信息，因为这些集合信息如果对外暴露不慎，就会破坏封装性，从而使得外部对象能够对其进行一些破坏性的修改。所以对外我们一般返回只读集合，这个问题在之前的文章不要对外公开泛型List成员中提到过。 问题的产生 下面以我们购物中的购物车为例来说明： public class Cart { private List<ProducItem> ProductItemsCollection; public Cart() { ProductItemsCollection = new List<ProducItem>(); } /// < …
写了一些文章，有一些自己比较满意，这些都是以系列的方式写的；还有一些写的比较随意，有凑数的嫌疑😂 (就像现在很多智能手机有很多摄像头一样，凑数的四摄🤣)，这里列出自己相对比较满意的文章，方便查看。 1.Excel开发系列 这个是我当年在某财经公司做Office插件开发时的一些新得和总结，毫不谦虚的说，大概是目前网上关于Office插件开发比较全的文章，这方面资料比较少，这些文章是在工作中跟同事以及在网上不断查找探索的总结。总共写了十一篇。 浅谈Excel开发：一 Excel 开发概述 浅谈Excel开发：二 Excel 菜单系统 浅谈Excel开发：三 Excel 对象模型 浅谈Excel开发：四 Excel 自定义函数 浅谈Excel开发：五 Excel RTD函数 浅谈Excel开发：六 Excel 异步自定义函数 浅谈Excel开发：七 Excel 自定义任务窗体 浅谈 …
最近几天在看一本名为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 …
在现在大型的项目或者软件开发中，一般都会有很多种终端， PC端比如Winform、WebForm，移动端，比如各种Native客户端(iOS, Android, WP)，Html5等，我们要满足以上所有这些客户端的需求，实现前后端的分离，一种最常见的做法是，编写WebService API来为以上客户端提供数据。近年来越来越多的企业或者网站支持Restfull方式的WebService，比如当当网开源Dubbox，扩展Dubbo服务框架支持REST风格远程调用，这个是Java版本的，在.NET中ServiceStack天生支持Restfull风格的WebService。本文主要以ServiceStack为基础探讨，浅谈API的兼容性设计。 1．软件的兼容性 在软件持续更新升级的过程中，API 也是需要不断更新，这时就需要考虑客户端升级以及兼容性的问题。当前有很多用户可能由于多种原因，尤 …
在常用的三层架构中，通常都是通过数据访问层来修改或者查询数据，一般修改和查询使用的是相同的实体。在一些业务逻辑简单的系统中可能没有什么问题，但是随着系统逻辑变得复杂，用户增多，这种设计就会出现一些性能问题。虽然在DB上可以做一些读写分离的设计，但在业务上如果在读写方面混合在一起的话，仍然会出现一些问题。 本文介绍了命令查询职责分离模式(Command Query Responsibility Segregation，CQRS)，该模式从业务上分离修改 (Command，增，删，改，会对系统状态进行修改)和查询（Query，查，不会对系统状态进行修改)的行为。从而使得逻辑更加清晰，便于对不同部分进行针对性的优化。文章首先简要介绍了传统的CRUD方式存在的问题，接着介绍了CQRS模式，最后以一个简单的在线日记系统演示了如何实现CQRS模式。要谈到读写操作，首先我们来看传统的CRUD的问题。 …
如果大家有印象的话，尤其是夏天，如果家里用电负载过大，比如开了很多家用电器，就会”自动跳闸”，此时电路就会断开。在以前更古老的一种方式是”保险丝”，当负载过大，或者电路发生故障或异常时，电流会不断升高，为防止升高的电流有可能损坏电路中的某些重要器件或贵重器件，烧毁电路甚至造成火灾。保险丝会在电流异常升高到一定的高度和热度的时候，自身熔断切断电流，从而起到保护电路安全运行的作用。 同样，在大型的软件系统中，如果调用的远程服务或者资源由于某种原因无法使用时，如果没有这种过载保护，就会导致请求的资源阻塞在服务器上等待从而耗尽系统或者服务器资源。很多时候刚开始可能只是系统出现了局部的、小规模的故障，然而由于种种原因，故障影响的范围越来越大，最终导致了全局性的后果。软件系统中的这种过载保护就是本文将要谈到的熔断器模式(Circuit Breaker) 一 问题的产生 在大型的分布式系统中，通常需要调 …
最近在阅读Framework Design Guidelines，本着现学现用的原则，于是就用FxCop工具对代码进行规范性检查时，发现了很多问题，其中包括命名以及一些设计上的规范。 其中，Do not expose generic lists 这条设计规范引起了我的注意。该规范指出“不要在对象模型中对外暴露List<T>，应该考虑使用Collection<T>,ReadOnlyCollection<T>或者KeyedCollection<K,V>，List<T>是原先ArrayList的泛型实现，是最基础的、性能最好和功能最强大的“动态数组”，对性能进行了优化，但是相对较“封闭”，入口较多。比如，如果奖List<T>对象返回给客户端，那么就不能实现诸如 …