Is & Is Not 这篇文章是…… 仅包含模式的名称、简要说明、结构类图和结构示例代码。 可用于快速浏览、回顾、查询及复习设计模式。 模式的意图和使用场合来自作者的个人实践总结。 虽然示例代码使用C#，但是尽量不会用到C#中特有的特性、接口及方法，而是起到一个通用框架说明的作用。 这篇文章不是…… 对设计模式面面俱到。 对设计模式详细而深入的探讨和研究。 从其它文献中照搬的东西。 保证绝对没有错误（虽然我尽我所能让其准确）。 讲述设计模式在C#中具体实现方法。 01 Abstract Factory（抽象工厂） 简要说明 抽象工厂模式拥有一组工厂类，这些工厂类实现同一个抽象工厂接口，这个接口定义了一系列创建方法，每一个方法创建一种产品，所有方法所创建的产品组成一个系列。不同的具体工厂类创建不同系列的系列产品，系列中每一种产

        SilverLight搭建WCF聊天室详细过程 系列文章为大家演示了如何使用SilverLight搭建WCF即时通讯系统过程，多人视频正在开发中，我会持续更新这个系列，以后几篇我会对群里提出最多的问题进行解答并给出设计思路，WCF和IIS配置已经包含在此系列，希望各位朋友在提问前先找找前面的帖子，QQ群：.NET集中营45656086，位置已经不多，群里高手很多，而且比较有开源精神，我是营长，有问题大家可以在博客园留言或者进营！         很多朋友在群里提问想知道SilverLight调用服务和WCF服务回调客户端的过程，我先给出大家这个过程的流程图，后面将会以聊天室为代码源通过代码为大家慢慢道来。   &n

memory cache + backing store enterprise libiary中的caching block 在微软pattern&practise团队发布的enterprise library5版本中带有一个caching block，这个缓存块为我们提供了缓存数据大一些列方法。其架构如下图（这里再说明一下：caching block以后会被整合进.net framework之中，enterlib5的后续版本会将caching block剔除）： caching block采用的是“内存缓存+backing store”结构（不过backing store是可选的），程序启动时缓存被加载到memory cache，也就是进程内存中（具体有两种加载策略，positive和reactive），当我们通过key调用对应的缓存项时首先在

缓存的加载策略--Proactive 和Reactive proactive的策略就是一开始就将所有backing store中的数据加载到进程内存中，这样做的好处是在数据量相对不大的时候会显得很有效率，无需频繁的访问backing store调出数据，并且也不用再代码中判断缓存中是否缓存有数据，是否要从backing store中加载。 reactive策略是“按需加载”，在程序初始化阶段仅加载必要的数据到内存缓存起来，其余数据只有在需要时才从数据库中调出再缓存。这种策略比较保守，缺点是在数据量比较大且频繁访问之初由于要多次频繁的向backing store获取数据，但通常我们使用这种的就是这种策略。 下面是两种方案的示例代码比较：proactive的方式Code highlighting produced by Actipro CodeHighlight

精灵的呈现基础 silverlight的那套api并不是一个为游戏设计的，你找不到现成的”精灵”相关的类。 最简单的精灵用一个Image就可以充当，但游戏中总是存在各式各样的精灵，不同精灵又有不同的逻辑，为了方便设计我们有必要定义一些接口。 呈现器接口—IPresenter IPresenterCode highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->namespace Sopaco.Silverlight.GameFramewrok.Sprite{    /// <summary>    //

    今年公司的Q12调查中我们项目组不理想，团队中主要的3个问题是： Q 4. 在过去的七天里，我因工作出色受到表扬认可和表扬如同建设良好的工作环境的砖和瓦。我们作为个人都需要获得认可，以及由此而生的成就感。盖洛普在研究中发现，表扬已成为了一种与员工有效的沟通方式。 Q7.在工作中，我觉得我的意见和建议受到重视所有员工都希望他们的意见受到公司的重视，而是否使员工有此种感觉又取决于公司如何倾听和对待他们的意见。这个问题往往被称为员工的 "内部股价"。它测量员工对工作和公司所产生的价值感，并能增强员工对公司的信心。 Q11 在过去的六个月内，工作单位有人和我谈及我的进步员工往往并不了解他们的才干在具体行为中会如何表现，他们需要从经理那里获得反馈来发挥才干和产生效益。优秀经理常常会不断的与员工进 行工作交流，并会谈及员工的进步，帮助员工认识和理

前篇回顾 从租车信息系统数据库设计（1）至租车信息系统数据库设计（4）我们完成了一个简单的租车信息系统的数据库设计。 从功能上来讲还有很多可以扩展的方面，如权限管理、发票管理等等，本文不将展开。大家可以对这些需求进行设想，设计相应的表、字段和关联，并融合到整体设计中。 本篇是本系列的最后一篇，我们将利用先前设计的数据库结构来写一些查询，完成一些业务需求，同时也反过来审视先前的设计。 获取需要催促还车的订单 我们的业务人员每天都要获取超出预订期限未还车的订单。对于这些订单，业务人员需要一一电话客户。 那就让我们来帮助业务人员写这个查询吧！ select RentalOrder.Order_ID from Table_Order RentalOrder where RentalOrder.Order_BookEndDate < GETDATE() and Orde

> 两年前，看了《情感化设计》很是感触，作者将设计分了层次分为三个层：本能、行为和反思，按我的理解是，界面、功能和自我实现，当然界面已经包含了产品的一切，但我指的仅仅是简单的界面层次，不包括由界面的功能层次。功能指的是产品所包括的功能，自我实现，这个词有点别扭，但我想不到别的词了，暂时用这个吧，自我实现指的是，系统营造的气氛给用户带来愉悦，让用户觉得有趣或者说有意思之类的感觉。这本书的理论很经典，可惜我做开发的，对于产品设计不是很了解，看不出这些理论有什么可操作性，很是迷惑就把书放下了，到现在，对于产品有了些许认识，也想把自己这些想法记录下来，当作自己的积累吧。   好的设计自然要是好看的，这一层不容置疑，但毕竟这一层是在需求之后的，也就是说必须先有功能，才到界面设计。那么先来说功能设计，什么用的功能是好的功能？对于用户来说，自然是用户最需要的功能且是好用易用的功能，说到这，得先

2  解决方案 1  简单工厂来解决         用来解决上述问题的一个合理的解决方案就是简单工厂，那么什么是简单工厂呢？1：简单工厂定义  2：应用简单工厂来解决的思路        分析上面的问题，虽然不能让模块外部知道模块内的具体实现，但是模块内部是可以知道实现类的，而且创建接口是需要具体实现类的。        那么干脆在模块内部新建一个类，在这个类里面来创建接口，然后把创建好的接口返回给客户端，这样外部应用就只需要根据这个类来获取相应的接口对象，然后就可以操作接口定义的方法了。把这样的对象称为简单工厂，就叫Factory吧。 &n

为什么需要单例模式        在很多项目中，我们可能都会遇到这样一种情况：某个类的对象在整个项目是唯一的，它不能也没必要被实例化多次，比如窗口管理器、皮肤加载器等等。这就催生出了如下的现实需求：如何确保某个类只有一个实例。        在结构化程序设计方法中，我们可以使用全局变量来实现唯一实例，但它不能保证唯一性，因为它无法确保使用者不在其他的地方进行实例化。在面向对象程序设计方法中，我们有了更好的选择；我们可以通过将类的构造函数隐藏起来，以防止用户多次实例化对象，同时给用户提供一个获取该类实例的接口。这样就从类本身保证了对象的唯一性，防止了用户的误用。 什么是单例模式        单例模式，又称单件模式

备注: 1.        模式常常组合使用，共同解决问题。 2.        模式是特定场景下优雅的解决方案，因此场景很关键。在软件设计中，特定的场景可能是显而易见的，可能是隐而不现的，有时甚至是设计者有意创造的。因此使用模式时，对问题的分析至关重要。 3.        模式的使用是有先后之分的。 4.        DP书中所给的结构图仅仅是模式可能的实现方式之一，但不是唯一。实现一个模式往往有多种途径。 5.     

走向ASP.NET架构设计-第七章-阶段总结—实践篇—中篇 　　前言：本篇接着上篇来。   本篇的议题如下： 示例说明（上篇） Domain Model（上篇） Repository（上篇） 服务层(中篇)          数据契约          服务契约          服务实现          宿主程序 代理层(下篇) 客户层(下篇)     　系列文章链接    &nb

  “Let your imagination release your imprisoned possibilities.” — Robert H. Schuller   　　每天清晨起来，我们新的一天就开始了。我们可以选择驱动今天，也可以选择由今天来驱动我们。当我们主动设计今天，那么我们就可以定义成功的标准，可以在今日的游戏中胜利，但我们要是被动的度过今天，那么可能明天我们就会独自一人在为今天后悔。   你的结果: 设计你的每一天，学会如何安排你的每一天来支持你取得成功  　　在30天敏捷结果：开篇中说到接下来我们将进行敏捷结果练习，前一篇学习了21：正面失败，吸取教训，改善结果，我们对失败有个重新的认识。今天我们要进行Getting Result练习的第22天：设计你的一天（Day 22 – D

    Silverlight中的ControlTemplate(1)-概念      Silverlight中的ControlTemplate(2)-概念      Silverlight中的ControlTemplate（3）-Blend设计ControlTemplate           上一篇我是通过Blend简单的演示如何修改ControlTemplate，这一篇关注VSM这个部分。     概念的东西就不再重复了，这篇通过Blend演示如何一步一步设计VisualStateManager     首先在WorkSpace上

    OEA框架的核心之一是AutoUI，其职责是面向领域模型及UI元模型进行生成统一的界面。     在本次的迭代开发中，需要对命令按钮的生成方式进行一些定制。由于原来并没有为这样的需求留有特别的扩展点，加之原来的生成代码是过程式的代码、且也变得比较冗长，所以我们决定对这一部分的代码进行重构。 原来的模式     历史代码中，为某一实体类生成命令按钮的流程是这样的： 找到实体类可用的所有命令按钮元数据。 对它们进行过滤，依靠权限、版本的客户化元信息等。 构造几个生成控件的List容器，分别是：itemsInToolbar，itemsInContextMenu，itemsInGroup。 遍历所有的命令按钮，根据其对应的元数据，分别生成相应的控件（按钮、菜单等），然后添加到容器中。其中，还有

  在网络编程中，我们会频繁用到两个东西，一个是buffer。一个是bit-order。把数据填充到buffer中，然后通过buffer读写我们所需要的基本数据，还好.NET为我们提供了BitConverter这个非常好用的util，方便我们编写自己的Buffer和字节序转换器。 IBuffer 通常Buffer会有如下几个概念；position,limit,capacity,flip,mark,reset,free position：即将读/写的位置 limit：有效读/写的极限位置 capacity：buffer的最大长度 flip：limit设为置position，position设为0 mark：记录当前的position，对应reset操作 reset：将position设置为之前mark的位置 free：将缓冲标识为空闲，可在入池前调用。 比

一、上篇回顾         通过上篇的简单讲解，我们知道了，组合模式意图是通过整体与局部之间的关系，通过树形结构的形式进行组织复杂对象，屏蔽对象内部的细节，对 外展现统一的方式来操作对象，是我们处理更复杂对象的一个手段和方式。本文以查询控件为例，说明了，查询控件内部的组成元素，及如何操作内部的组 成元素，包括添加元素，删除和处理相应事件的Handler，当然组合模式的作用远比这些强大，后面我们肯定会在一些实例代码中运用到组合模式的。组合 模式如果在条件允许的情况下，我们尽量使用组合模式来处理复杂对象，远比通过继承出来的对象来的有效。         组合模式-强调的是如何组织整体和局部之间的结构，将整体和局部之间的关系，通过树形这样的结构来组织这种

昨天项目组进行了一个设计评审，主要是对OpenExpressApp的AutoUI部分进行重构，我相当于评审人。大家也可以把这个评审过程当做与人交流你的设计思路的一个过程，以下从我评审的一些要素来谈谈与人交流设计思路时需要考虑的内容，也许对大家在实际工作中的架构、设计和沟通都有所帮助。 　　评审并不是审判，你直接说出结果之后，然后等着判官下笔，评审一定是基于特定主题进行的，所讨论的东西都围绕这个主题，那么如何让人先清晰你的这个主题是需要考虑的。对于不同人来说，每个人关注视角不一样，所以还需要针对这个主题，对于不同场合、不同参与者，你需要使用什么方式来讲哪些内容才能够让参与者都清晰。 影响我评审关注的一些观点 技术是为业务服务的，再考虑技术时一定需要想想为实际业务做了什么 你清楚的别人不一定清楚一般自己做的设计会觉得很简单，可维护很好，但是没有做过的人理解起来很可能是相反的 你觉得简单的别人

     继续上节《基于Silverlight智能表单设计开发(三)》，在上一节中我对智能表单设计中带锚点的矩形编辑框类(DesignRectangle)和控件尺寸处理类(ResizeHelper)及控件拖动处理类(DragHelper)进行了分析和简单的代码实现。在这一节我主要是将窗体控件（WindowForm）的设计、开发关键点写出来与大家交流、学习。      与以前章节一样，我先把与WindowForm窗体控件相关的类关系图展现给大家看一下，对照下图我对图中所涉及元素做一简要说明： ICtr：是指所有控件的接口。如：文本控件、日期控件等等。 IForm：是指窗体控件的接口，即WindowForm窗体类要实现的接口。 DesignRectangle：它的实现就不多说了，在上一节中有详细介绍。在本节中通过

一、上篇回顾       我们上篇主要讲述了结构型模式中的外观模式，外观模式作为结构型模式中的一个简单又实用的模式，外观模式通过封装细节来提供大粒度的调用， 直接的好处就是，封装细节，提供了应用写程序的可维护性和易用性。外观模式一般应用在系统架构的服务层中，当我们是多个不同类型的客户端应用程序 时，比如一个系统既可以在通过Web的形式访问，也可以通过客户端应用程序的形式时，可能通过外观模式来提供远程服务，让应用程序进行远程调用， 这样通过外观形式提供服务，那么不管是什么样的客户端都访问一致的外观服务，那么以后就算是我们的应用服务发生变化，那么我们不需要修改没一个客 户端应用的调用，只需要修改相应的外观应用即可。 我们主要是讲述了以下的几种情况，使用外观模式可能更适合：