本系列第一篇发出来之后，与钧梓昊逑讨论了一些问题，现整理出来
（钧梓昊逑是我的入门老师~非常牛的技术天才~现在开始涉足西洋乐器领域~希望他能早日超过贝多芬~为山寨党众同仁争光~）
一：关于职责问题
客户端的主要职责负责呈现，不宜有过多的业务逻辑
与业务相关的代码和访问数据库相关的代码放在服务器端
与呈现相关的代码放在客户端
至于哪些代码是与业务相关的，哪些代码是与呈现相关的
呈现的代码是不是包含了业务，业务的代码是不是牵涉到呈现
这属于边界划分的问题,仁者见仁~智者见智~也要根据项目具体问题具体分析
二：关于容错的问题
容错代码服务端和客户端都有
业务上的容错放在服务端，交互上的容错放在客户端
（如果客户端不是自己做的，那么服务端的容错就要全部包含，这不是咱们讨论的范畴）
交互上的容错和业务上的容错是不一样的
服务端认为接收到的数据在格式上都是正确的，但在业务上不一定正确。
三：安全性问题
如果是安全性要求相对较高的领域，比如金融领域
就要仔细考虑到客户端验证的问题 ,
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读了很多书~学习能力非常强~
但同时他也是强烈的种族主义者~中国版的希特勒~（用希特勒形容他，他肯定以为我在侮辱他）
好吧~学飞~你再不给我点推荐我就真不跟你玩了~
---
同时~读到这篇文章的朋友们~你如果觉得还有点意思~就点一下推荐吧~~~