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

本系列第一篇发出来之后，与钧梓昊逑讨论了一些问题，现整理出来

（钧梓昊逑是我的入门老师~非常牛的技术天才~现在开始涉足西洋乐器领域~希望他能早日超过贝多芬~为山寨党众同仁争光~）

一：关于职责问题

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

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

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

至于哪些代码是与业务相关的，哪些代码是与呈现相关的

呈现的代码是不是包含了业务，业务的代码是不是牵涉到呈现

这属于边界划分的问题,仁者见仁~智者见智~也要根据项目具体问题具体分析

二：关于容错的问题

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

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

（如果客户端不是自己做的，那么服务端的容错就要全部包含，这不是咱们讨论的范畴）

交互上的容错和业务上的容错是不一样的

服务端认为接收到的数据在格式上都是正确的，但在业务上不一定正确。

三：安全性问题

如果是安全性要求相对较高的领域，比如金融领域

就要仔细考虑到客户端验证的问题 ,

1使用数字证书

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

3用加密狗启动客户端

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

各有利弊~自己权衡~不深入讨论

四：框架复用的问题

我脚的一个框架 并不是给成百上千个项目用，

很多时候只是给一两个、两三个项目用

所以不要把过多精力花在兼容不同的业务问题上

或许有人会说这么做是为了最大限度的复用这个框架，

这也要看各自把握的程度了~仁者见仁~智者见智~

只给一个项目用的框架~也挺好~

能把很多业务上的东西抽象到框架中，减少编码人员的工作量，框架也不显着复杂难用！

----------------

五：关于ORM

本系列中没用用到ORM~下一个系列中会用到~这不是承诺

好吧~言归正传

一：团队内部的约定



我们根据主菜单把系统的业务划分成12块

（当然会根据业务的增加而增加新的模块，不会影响既有框架）

下面看一下程序集的目录结构











当我们的框架设计完成之后

要求编码人员按照约定好的目录结构完成 相应的业务代码

编码人员几乎不用关心任何与自己业务无关的内容。

约定一：

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

约定二：

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

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

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

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

约定三：

实体类名必须以Model结尾

窗体类名必须以Form结尾

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

----

如果你觉得这些约定实在过于繁琐~

好吧~随便你~

二：按约定动态发现WCF服务

有了上面的约定，想要动态发现WCF服务，就简单了

看代码

public class ClientFactory<TClient> : IDisposable
{
static EndpointAddress serviceAddress;
static BasicHttpBinding binding;
ChannelFactory<TClient> factory;
public TClient CreateClient()
{
factory = new ChannelFactory<TClient>(binding, serviceAddress);
TClient result = factory.CreateChannel();
return result;
}
static ClientFactory()
{
var surl = ConfigurationManager.AppSettings["ServiceURL"];
var iname = typeof(TClient).FullName.Substring("XL.ServiceAPI.".Length);
iname = iname.Replace(".I", "-");
var sname = string.Format("{0}Service", iname);
var url = Path.Combine(surl, sname);
serviceAddress = new EndpointAddress(url);

binding = new BasicHttpBinding();
binding.CloseTimeout = new TimeSpan(10, 10, 10);
binding.OpenTimeout = new TimeSpan(10, 10, 10);
binding.SendTimeout = new TimeSpan(10, 10, 10);
binding.ReceiveTimeout = new TimeSpan(10, 10, 10);
}
public void Dispose()
{
factory.Close();
}
}

这个类需要一个“类型形参”，这个类型形参就是我们的服务接口类型

静态的构造函数只会执行一次

appconfig文件中放着WCF服务的基础地址

<configuration>
<appSettings>
<add key="ServiceURL" value="http://localhost/XL.Service" />
</appSettings>
</configuration>

接下来就是按照游戏规则构造出了一个WCF Service的地址

形如：http://localhost/XL.Service/Sys-MenuService　　

（亲~我修改了上一篇中创建服务的内容~）

静态的构造函数做的主要还是准备工作，CreateClient方法才是真正的创建了服务通道

它反馈的是一个TClient的实例。

也就是一个实现了WCF服务接口的实例，我们可以使用这个实例来调用WCF服务

下面我们看看如何调用WCF

var factory = new Common.ClientFactory<IMenu>();
try
{
var Menus = factory.CreateClient().GetAllMenu();
}
catch (Exception ex)
{
Utils.Alert(ex.Message);
}
factory.Dispose();

如你所见，我们使用了什么接口类型作为类型形参

CreateClient就会反馈给我们什么类型的信道实例

我们就可以用这个信道实例，完成WCF接口描述的各种行为了

下一节咱们就说客户端框架窗体和动态菜单了~~

另：

xuefly读了很多书~学习能力非常强~

但同时他也是强烈的种族主义者~中国版的希特勒~（用希特勒形容他，他肯定以为我在侮辱他）

好吧~学飞~你再不给我点推荐我就真不跟你玩了~

---

同时~读到这篇文章的朋友们~你如果觉得还有点意思~就点一下推荐吧~~~