本系列第一篇发出来之后,与钧梓昊逑讨论了一些问题,现整理出来
一:关于职责问题
客户端的主要职责负责呈现,不宜有过多的业务逻辑
与业务相关的代码和访问数据库相关的代码放在服务器端
与呈现相关的代码放在客户端
至于哪些代码是与业务相关的,哪些代码是与呈现相关的
呈现的代码是不是包含了业务,业务的代码是不是牵涉到呈现
这属于边界划分的问题,仁者见仁~智者见智~也要根据项目具体问题具体分析
二:关于容错的问题
容错代码服务端和客户端都有
业务上的容错放在服务端,交互上的容错放在客户端
(如果客户端不是自己做的,那么服务端的容错就要全部包含,这不是咱们讨论的范畴)
交互上的容错和业务上的容错是不一样的
服务端认为接收到的数据在格式上都是正确的,但在业务上不一定正确。
三:安全性问题
如果是安全性要求相对较高的领域,比如金融领域
就要仔细考虑到客户端验证的问题 ,
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接口描述的各种行为了
下一节咱们就说客户端框架窗体和动态菜单了~~