WinForm企业应用框架设计——笔记

WinForm企业应用框架设计【一】界限划分与动态创建WCF服务（no svc!no serviceActivations!）

WinForm企业应用框架设计【二】团队内部的约定和客户端按约定识别WCF服务

WinForm企业应用框架设计【三】框架窗体设计；动态创建菜单；

WinForm企业应用框架设计【四】动态创建业务窗体

WinForm企业应用框架设计【五】系统登录以及身份验证+源码

拜读之后，觉得还是写写笔记记得牢一些，如下：

一界限划分与动态创建WCF服务（no svc!no serviceActivations!）

一：界限划分

如图所示,几个程序集的含义如下：

XL.Client【客户端程序】

XL.DataAccess 【数据库访问层】

XL.Models 【实体层】

XL.Service【WCF服务层】

XL.ServiceAPI 【服务接口】（全部是接口）

XL.Setup【安装包】

这就是一个典型的CS程序的程序集列表

客户端中：

XL.Client将引用 XL.Models和XL.ServiceAPI

服务端 中：

XL.Service将引用 XL.Models和XL.ServiceAPI和XL.DataAccess

二：动态创建WCF服务

创建wcf服务通过工厂类实现，遍历程序集后，找到以service结束的类，放入RouteTable中。

原则：约定由于配置的原则！

 

二团队内部的约定和客户端按约定识别WCF服务

1：关于职责问题

客户端的主要职责负责呈现，不宜有过多的业务逻辑

与业务相关的代码和访问数据库相关的代码放在服务器端

与呈现相关的代码放在客户端 

2关于容错的问题

容错代码服务端和客户端都有

业务上的容错放在服务端，交互上的容错放在客户端

3 安全性问题

a使用数字证书

b在SOAP消息头里加入一串DES密文

c用加密狗启动客户端

d通过硬件串号来识别客户端

4框架复用的问题

我脚的一个框架  并不是给成百上千个项目用，很多时候只是给一两个、两三个项目用

5团队内部的约定

约定一：

每个模块的代码放到相应的文件夹下去

约定二：

WCF服务接口类名必须以I开头；

WCF服务类名必须以Service结尾；

接口类名去掉I字母 ==  服务类名去掉Service结尾

亲~要不然客户端会找不到服务哦

约定三：

实体类名必须以Model结尾

窗体类名必须以Form结尾

数据库访问类名必须以DA结尾

6按约定动态发现WCF服务(客户端)

 

 

三框架窗体设计+动态创建菜单

1框架窗体

框架窗体分管布局的只有四个Panel；

上、下、左、右。（搞过EXTJS的人比较喜欢说成东、南、西、北）-_-!

最上面的Panel是存放顶级菜单用的 (top menu)

最下面的panel是存放状态信息和系统版本用的

左边的Panel又分为两个panel

2动态创建顶部菜单

先看CreateTopMenu

/// <summary>

/// 创建顶部菜单

/// </summary>

private void CreateTopMenu()

{

    var tmms = (from v in Menus where v.ParentId == Guid.Empty orderby v.OrderNum select v).ToList();

    for (var i = 0; i < tmms.Count; i++)

    {

        var ctl = CreateOneTopMenu(tmms[i], i);

        TopMenuP.Controls.Add(ctl);

    }

}

Createonetopmenu(m,i)函数会自动在pannel中创建控件，并绑定一些常用事件。注意这些事件是这些控件公用的事件，比如鼠标放上去，颜色变色等。

3动态创建子菜单

private void CreateSubMenu(MenuModeltm)

{

    SubHeaderLB.Text =tm.MenuName;

    SubMenuP.Controls.Clear();

    var smms = (from v in Menus where v.ParentId == tm.Idorderby v.OrderNum select v).ToList();

    for (var i = 0; i <smms.Count; i++)

    {

        var ctl = CreateOneSubMenu(smms[i], i);

        SubMenuP.Controls.Add(ctl);

    }

}

 

 

四动态创建业务窗体

1自定义Tab按钮

我们的tab按钮左部是文字；右部是关闭按钮；并定义了鼠标划入状态，选中状态等。

然后再根据鼠标的位置以不同的颜色绘制控件，此部分涉及到gdi+的内容。

2业务窗体的基类

即点击菜单兰后，如何弹出对应窗体呢？我们把每个窗体放在菜单栏按钮的tag中，点击时先判断tag中保存了什么menumodel，再根据CreateOneForm（menumodel）创建对应的窗体。

private BaseForm CreateOneForm(MenuModel m)

       {

           var ass = this.GetType().Assembly;

           var url = string.Format("XL.Client.Forms.{0}", m.Url);

           BaseForm f = null;

           try

           {

                f = ass.CreateInstance(url) asBaseForm;

           }

           catch

           {

                Utils.Alert("没有与此菜单相关的业务窗体");

                return null;

           }

           f.Dock = DockStyle.Fill;

           f.FormMenu = m;

           var tabBtn = new TabBTN();

           tabBtn.OnClose += new EventHandler(f.tbn_OnClose);

           tabBtn.OnSelect += new EventHandler(f.tbn_OnSelect);

           tabBtn.Caption = m.MenuName;

           int left = 6;

           var tabCount = TabContainerP.Controls.Count;

           if (tabCount > 0)

            {

                var lastTab =TabContainerP.Controls[tabCount - 1];

                left += (lastTab.Left +lastTab.Width);

           }

           tabBtn.Left = left;

           TabContainerP.Controls.Add(tabBtn);

           f.FormTabBTN = tabBtn;

           return f;

       }

 

五系统登录以及身份验证+源码

1登录的画面与客户端逻辑

当点击登录之后，

会把用户输入的用户名和密码传迪到服务端，并得到当前用户实体

CacheStrategy.CurUser= CurUser;

2每次与WCF交互都传递标识信息

登录之后的每次服务端交互，服务端都要确认当前的客户端的正确性。为了做到这一点，我们就要在每次与WCF交互的时候，把客户端的身份传递给服务器端，并在服务端缓存起来。

3服务端的验证

为了对客户端的操作进行身份验证，我们设计了一个所有服务类的基类

[AspNetCompatibilityRequirements(RequirementsMode =AspNetCompatibilityRequirementsMode.Required)]
[ServiceBehavior(IncludeExceptionDetailInFaults = true)]

此两个类属性放在服务基类里，服务子类就不用再写这两个属性了

4客户端对验证消息的处理

在服务端基类里我们对验证不通过的客户抛出了一个异常

如果异常，服务端“特意”返回的

我们就让客户端重新登录

 

结语，读完之后感觉对wcf这块还是要加强学习，不太懂~~再研究下源码！