该总结的东西都总结得差不多了，剩下的都是一些细枝末节的了，基本可以收尾了，这一篇讲一讲设计模式。

设计模式是个什么东西，它其实只是前人在当前系统实现基本手段基础上提取出来的一些方法论，目的是为了更好更快的解决我们在系统实现中碰到的各种问题。其实如果总是处于那种“你来我往”的状态之中，没有静下心来细细的思量，无法把握到项目的全貌，没有精益求精的态度，那些方法论不用也罢。可幸这一次上述的如果都没有，所以才能一直写这个系统的总结写了二十来篇，可谓收获颇丰。

一、创建型模式

创建型模式里用得比较多，也比较好掌握的就是Singleton模式了，这个模式对于实现者的设计能力要求不甚高，这也是我最早运用的模式之一。在此次系统实现中当然也不会少，不过其中由于环境特性，我有些实现的地方并没有用标准的方法，而是简化了。那些地方可以说徒有其名而无其实，但最终的效果还是一样的。

Factory与Abstract Factory模式是比较耳熟能详的二个模式，其二者很容易混淆起来，其实我在运用它们的时候也不是非常的得心应手，总的来说实现了一种设计后并不能严格意义上区分它是哪一个模式。对于很多的模式都有这种感觉，特别是当一个设计开始趋向有层次的复杂之后，这从另一方面印证了设计模式是一种特定条件下的方法论的观点。

在这一次的系统中并没有很多的、很复杂的类的创建，所以Prototype与Builder模式也无从谈起。系统中类的创建要化点脑筋的就数硬件访问与服务加载了，二者实现手段是一致的。都是先提取一个公共的接口，系统启动创建时，根据配置文件创建相关类，并设置相关属性，最后把创建出来的类放入到一个集合中供系统调用。这里有Abstract Factory，也有Bridge以及Iterator。

二、结构型模式

Adapter在这新的系统用处不大，但Bridge则大有用武之地。特定硬件与系统的解耦就是通过Bridge来实现的，还记得硬件访问时提取出来的那个接口吗？那个接口与我们封装过的特定硬件访问类之间就是桥的关系。

硬件技术总归是一种比较复杂的东西，我们的系统利用的只是它们功能的小部分，同时厂商提供的硬件访问API对于系统是很不友好的，它对于我们暴露了过多的细节，这时Facade模式就派上用场了。所以硬件访问这一块是在Facade基础上的Bridge。

其实数据通讯这一块跟硬件访问有异曲同工之妙，通讯组件的逻辑封装与技术封装之间可以认为有Bridge，即不同的通讯技术对于客户端的最终调用是不透明的；而技术封装本身就是一个Facade。

Composite模式最通常的应用就是菜单类了。而Decorator模式在我看来是无处不在，这个模式是“优先使用对象组合，而不用类继承”的典型体现。我说这个模式无处不在并不是说系统中大量充斥着一个个的Decorator，而是说明对象组合的普遍性。最能体现Decorator的价值的地方是数据对象的查询条件、排序设置，数据对象EntityBase与查询条件WhereCondition之间是Decorator关系，而WhereCondition内部则是Composite关系。

Flyweight与Proxy在系统中没有很明显的应用。

三、行为型模式

相比前二类模式，行为型模式似乎比较的深奥一点，以前有几次出去面试时，居然不止一次的发现有些人不了解其中的一些模式。抛开一些个体的因素不谈，个人认为行为模式显得“深奥”正是反应了我们真实世界的多变复杂性。我们的世界是如此的难以琢磨，而行为型模式对于这个世界相比前二类模式有更深的介入，以至于我们在运用这一类的模式时有时会很不好权衡利弊。

Command模式，每次提到时好象都拿菜单与工具栏说事，这个运用也是比较的普遍，这一次实现系统当然也就没有放过它。

Iterator模式在行为型模式中算是比较“大众化”的一个模式了，因为集合的运用对于每一个系统实现者来说都是非常必要的，而现在绝大多数的系统框架在集合类的实现上都体现了这个模式的精髓。而Observer是另一个系统框架涉及比较多的模式，事件-委托机制就可以认为是这个模式一种表现。集合与事件是在系统设计与实现中大量运用的，上述二种模式当然就逃不过。

State模式在这次的系统实现的运用中不是非常的到位，因为虽然窗体状态看起来也挺多，但对于界面变化来讲只分为浏览与非浏览二种，而各个状态的操作只有一个“确定”是各异的。State模式在这个场景显得有点鸡肋。

Strategy本来是没什么机会用的，不过在管控端有一个功能，就是显示座位，座位号的排列并不是每次都是从左到右来的，这里有个排座策略问题，这个模式恰好排上用场。

Template Method是行为模式中在我看来运用得很频繁的一个模式，这次系统实现中也大量的运用，比如在单数据窗体中工具栏按钮事件中的一串方法，还有在数据访问对象中的很多方法。其实象这种由父类放一个钩子出去，然后子类Override相关方法实现具体操作的用法，在很久以前还不知道设计模式这个东西的时候就在使用了。

剩下的其他行为型模式有些有太特殊的应用场景(如Interpret)，而有些虽然可以应用到系统中，但鉴于系统需求没有那么深入，犯不着为了一个设计模式复杂化整个系统(如Memento)。

最后数了一下，在这次系统实现中共用了12个模式，占了Gof设计模式的一半强，可以说“麻雀虽小，五脏俱全”。半年来的经历比之过去几年的收获还大，当然没有之前的积累也一下子用不上这么多的设计模式，总之过去的那半年虽然没有投身到新技术的大潮中，但还是很值得。

这一篇其实没什么可讲的，只提一下跟客户端不太一样的一些地方。

服务端跟客户端最大的区别是它面对的不是单单一个连接，而是有一些个连接。对于接收与发送来讲它是要具体到accept进来的每一个连接的，所以这里有一个SocketStateObject参数会贯穿始终，这个参数主要就是放对应客户端的Socket连接及一些状态变量，在accept进来一个连接后即创建一个这个对象。

       public void Listen(int port)

       {         

           IPEndPoint ipe = new IPEndPoint(IPAddress.Any,port);

           workSock = new Socket(ipe.AddressFamily,SocketType.Stream,ProtocolType.Tcp);

           workSock.Bind(ipe);

           workSock.Listen(100);

           acpT = new Thread(new ThreadStart(acceptThread));

           acpT.IsBackground = true;

           acpT.Start();

       }

       private void acceptThread()

       {

           while(true)

           {

              Socket asock = workSock.Accept();

              SocketStateObject state = new SocketStateObject(asock);    

              if (OnConnect != null)

                  OnConnect(state,System.EventArgs.Empty);

               ThreadPool.QueueUserWorkItem(new WaitCallback(ReceiveThreadEntryPoint),state);

           }

       }

象上面OnConnect事件及ReceiveThreadEntryPoint方法里都会跟进这么一个参数。

管理连接是个很复杂、很讲究技术的活。可用连接的数据接收与发送（甚至有些接收与发送必须是相关的）、连接的可用性监测、失效连接的移除。所有这些都要作应有的记录，并且一些还要往UI界面触发事件，事件触发这一点至关重要，也最为棘手，这其中涉及到很多线程同步、线程阻塞的问题。

对于这种极为复杂的问题，最好的解决方法是参照现有的成熟方案进行设计、实现或者拿来主义。但之前也没涉足到这些方面的开发，一时还真找不到比较理想的东西，加之项目本身对于通讯的要求不甚高，10个连接顶天了（如果真有哪个客户要10个签到终端，那真是绝对的上帝了，至目前为止最多的也就5个终端，一般不会多于3个），所以在这次开发中我就用了一些简单的方法来管理客户端的连接。

由于这一块并没有经过认真的设计，也暂时无力作认真的设计，最后实现的东西自己也不满意，这里就不去讲述如何实现管理连接的了。

经过上一篇定义的两个接口，菜单与工具栏基本上符合了Command模式的样子，接下来应该可以在系统中加载了。但理论上照着模式是一回事，实实在在的写代码又是另一回事。

我们很遗憾地发现ToolBarButton这个类根本没有单击事件，甚至跟UI有关的事件都没有一个，因为它根本就不是从Control继承的，而是从Component继承的。工具栏按钮单击是从工具栏ToolBar的ButtonClick事件来的，就是说如果你要挂一段单击工具栏上单个按钮时发生动作的代码得挂在ToolBar的事件上，除些之外别无它法，很奇怪的设计。这种ToolBar只能用在静态的地方（其实即使是静态的地方，这个ButtonClick事件也是很糟糕的，以后会看到静态工具栏的这个变态事件），对于动态工具栏.Net Framework自带的这个ToolBar实在是无能为力。

没辙了，改吧。我们自己放个单击事件出来。下面是ToolBarButton的完整代码：

ToolBarButton
      public class CommandToolBarButton : ToolBarButton,ICommandHolder

      {

             private string _ID;

             private ICommand command;

 

             public event EventHandler OnClick;

 

             public string ID 

             {

                    get { return _ID; }

                    set { _ID = value; }

             }

 

             public CommandToolBarButton(string name) : base(name){}

 

             ICommandHolder 成员#region ICommandHolder 成员

 

             public ICommand GetCommand()

             {

                    return command;

             }

 

             public void SetCommand(ICommand cmd)

             {

                    command = cmd;

             }

 

             #endregion

 

             internal virtual void DoOnClick(){

                    if (OnClick != null)

                           OnClick(this,System.EventArgs.Empty);

             }

 

      }

为了让ToolBar能认识这个Button，我们还得对ToolBar作点小小的改造，要让它可以触发ToolBarButton的单击事件。

       protected override void WndProc(ref Message m) {

           if (m.Msg == 0x2111){

              int index = ((int) m.WParam) & 0xffff;

              ToolBarButton button = this.Buttons[index];

              if (button != null) {

                  CommandToolBarButton commandBtn = button as CommandToolBarButton;

                  if (commandBtn != null){

                     commandBtn.DoOnClick();

                  }else{

                     ToolBarButtonClickEventArgs args1 = new ToolBarButtonClickEventArgs(button);

                     this.OnButtonClick(args1);

                  }

              }

           }else

              base.WndProc (ref m);

           base.ResetMouseEventArgs();

       }

上面代码里有个Magic Number，它在Win32 API里表示进入菜单循环消息（WM_ENTERMENULOOP，注意不是写在单击消息里的），因为项目里这种Message常量用得不多，就偷懒一下直接写了。

本要接上一篇开始讲管控端程序的菜单与工具栏的加载，但发现还是先要讲一下整个管控端的窗体组织，否则会无法理解菜单事件为何要那么写。

多窗体组织很经典的模型就是MDI了，但MDI在窗体最大化、最小化、还原一些动作之后，窗体会乱掉，很乱七八糟。现在的程序很少有用那种原始的MDI来作界面的了，至少我不会去用，实在是难看。但开发工具在这里也是没有长进，如果我们直接用IDE只能生成那种原始的MDI窗体。

只能另想办法，其实也没多想，因为以前（一年多前）曾经为同学做过一个DEMO，当时也是基于难看的MDI，在SourceForge上找了这个DockPanel（从作者名字看象是一个华人的作品，现在已经是2.0了，我当时还是1.0。下面我所述的都是基于1.0的基础上的），做出了相对比较悦目的界面，这东西没有用GPL之类的开源协议，这次当然也就顺手用上了（其实即使它用了GPL，我用它了，公司也没人管我，他们只关心项目有没有按时完成。有否金玉其外、败絮其中都无瑕顾及，还会去顾及这个国人很少注意的Open Source License吗？）。

用这个DockPanel能做出什么界面这里不具体说了，基本可以用它做出如VS.net那样的界面，不过对我来说用不了那么多功能，用得最多的就是“多Tab显示窗体”。当然基于那个DockPanel我作了一些小小的修改。

当双击Tab时，原先是直接把当前Tab所表示的这个窗体，从主窗体的框架上分离现来，成为一个浮动的窗体。这不是我想要的，我把它改成了双击关闭。

在DockPaneStripBase的WndProc方法里，对于左键双击消息重新作了处理（下面注释掉的一行是原先的写法，它下面那行是我改的）：

           else if (m.Msg == (int)Win32.Msgs.WM_LBUTTONDBLCLK)

           {

              base.WndProc(ref m);

              int index = GetHitTest();

              if (DockPane.DockPanel.AllowRedocking && index != -1)

              {

                  IDockContent content = Tabs[index].Content;

                  try {  

//                   content.DockHandler.IsFloat = !content.DockHandler.IsFloat;

                     content.DockHandler.Close();

                  }  

                  catch  {   }

              }

              return;

           }

另外改的一个地方，这一次系统里没有派上用场，不过也顺便提一下。是关于主窗背景色（图）的，因为这次的管控端系统，系统运行中一般是会有一个窗体一直开启着的（就是那个签到统计显示的窗体），背景对于使用者反而是不可见的。

DockPanel的OnPaint方法里，原来对于背景设置是不起作用的，我把它改了一下：

       protected override void OnPaint(PaintEventArgs e)

       {

           base.OnPaint(e);

           Graphics g = e.Graphics;

//         g.FillRectangle(SystemBrushes.AppWorkspace, ClientRectangle);

           if (this.BackgroundImage != null)

              g.FillRectangle(new TextureBrush(this.BackgroundImage),ClientRectangle);

           else

              g.FillRectangle(new SolidBrush(this.BackColor),ClientRectangle);

       }

从上面我们知道现在管控端不再是一个孤零零的应用程序，而是由一些模块组成的，这些模块可能会根据不同情况有各种的组合，这样程序中就不能把模块写死了，而是得动态加载，反射又要派上用场了。

本来想如一些应用一样把业务模块当成是一个个的插件，然后把相应程序集放入类似于Plugins的目录，程序启动时到相应目录去寻找相应程序集这样的机制来加载的。但考虑到业务模块不会很多，引用的程序集也不会很复杂，可以预见以后也不会增加很多，为了简便起见，现把所有的程序集都放在应用程序根目录下。虽然可能会发生版本冲突之类的问题，但对于一个相对简单的应用来讲应该是合适的。

这里的东西其实没什么新意，整个做法跟前面硬件访问是如出一辙的。首先所有可被管控端加载的业务模块要实现如下的接口：

业务模块接口
      public interface IService

      {     

             string Name

             {

                    get; set;

             }

 

             /**//// 主应用窗体相关内容

             ServiceContext Context

             {

                    get; set;

             }

 

             /**//// 加载菜单、工具栏

             void LoadCommand();

             /**//// 初始化工作

             void Initialize();

             /**//// 服务终止工作

             void Finalize();

             /**//// 注册可以让HOST调用的方法

             void RegisterMethod(Hashtable methodDictionary);

      }

Context：这里主要就是存放各个业务模块加载时需要的主程序的菜单、工具栏。

LoadCommand：加载这个业务模块所具有的菜单、工具栏，具体做法下面几篇会讲到。

Initialize与Finalize：加载模块时除菜单、工具栏外其他一些需要的工作可以在这里完成。比如签到控制模块，通讯端口的开启与关闭。

RegisterMothod：业务模块对于主程序来讲是不可知的，这里可以注册一些方法让主程序调用到它的方法。这是后来加的功能，没有设计好，用了一个Hashtable来存放各个模块的方法委托，好在用得上的地方不是很多。

再来看一下配置：

    <Services>

       <Service Order="1" Name="SignInService" Startup="BCSMService.SignInSrv.SignInRunner,SignInSrv" />

       <Service ...... />

       <Service ...... />

    </Services>

应用上面的配置加载，