设计并不是一定需要设计模式，有时使用设计模式还不如不使用设计模式更简洁。所以，我所讲述的模块设计中使用的设计模式不一定正确，只作为一种过程记录。

       框架的主题已经搭建完成，现在要让框架提供一些系统服务，好方便客户端的开发和使用服务端提供的服务。其中，有这样一个需求：客户端想要知道服务端服务目录下所有文件夹和文件的信息，并且客户端从服务端获取的数据可以方便以树型结构显示。

       拿到这个需求后，我是这么想的：

1、 服务端需要提供查询文件目录的服务，这个很好实现，调用.net提供的类库检索目录结构就可以了。功能实现后，还应该考虑一些什么呢？我想今天需要一个目录的信息服务，那明天会不会又要提供一个服务列表的服务呢？后天又会是什么？基于这种考虑，为了能不断扩展针对不同事物的信息获取，我选择了command模式，通过不同的命令对象实现不同的信息获取或者相关操作，方便以后不同信息服务的扩展。（这里并不是非得使用command模式，我只是考虑减少负责命令调用类和各种不同命令类之间的耦合。）

2、 信息获取后，应该以何种方式组织，这样客户端可方便遍历这些信息？针对文件目录特点和客户端以目录树结构显示要求，那么对于文件目录服务返回的目录信息组织是通过compostie模式实现。这样比将获得的字符信息连接起来传到客户端分析更有结构感。

设计简图：

InformationCmd：是信息命令的基类，可以继承它扩展其他的信息命令

FileCmd：文件命令，比如获取文件夹下的所有文件目录等

FileOperation:：封装了文件及文件夹操作

InfoComposite、InfoLeaf和InfoContainer是用于保存获取的文件和目录信息

///<summary>

        ///显示树结构
       ///</summary>

        ///<param name="composite"></param>

        private void ShowTree(Sptes.Framework.Information.Common.InfoComposite<string> composite)

        {

            TreeNode root = new TreeNode();

            root.Text = composite.InfoData;

            this.treeView1.Nodes.Add(root);

            ShowTree(composite, root);           

        }

        ///<summary>

        ///显示树结构

        ///</summary>

        ///<param name="composite"></param>

        private void ShowTree(Sptes.Framework.Information.Common.InfoComposite<string> composite,TreeNode node)

        {

            foreach(InfoComposite<string> temp in composite.ItemList)

            {

                if(temp.IsContainer)

                {

                    TreeNode subNode = new TreeNode();

                    subNode.Text = temp.InfoData;

                    node.Nodes.Add(subNode);

                    ShowTree(temp, subNode);                   

                }

                else

                {

                    TreeNode subNode = new TreeNode();

                    subNode.Text = temp.InfoData;

                    node.Nodes.Add(subNode);

                }

            }

        }