WCF 项目应用连载[6] - 升级Lig服务 - 设计ILigger 构建一个完善的Lig版本

前面我们已经搞定了对ChannelFactory与ServiceHost的扩展，形成了我们自己用的两个类：

public class LWCF<T>
public class LServiceHost : ServiceHost

现在我们是有机会来完善Lig版本了。这次，我们将彻底的改善一下Lig系统，让其能真正成为一个可用并且完美的版本。。。。。

6.1 设计ILigger接口

如图6.1所示。我们为Lig工程增加Ligger库类项目。



图6.1 升级版本的Lig代码结构

6.1.1 并增加如入下接口ILigger：

1)多了两个属性

ConnectStatus ： WCF连接标志

ClientID ： 客户端ID

2）多了一个含委托参数的接口

我们看到客户端中多了SubscribeOnlineEvent并且带存在EventHandler委托参数，我们为该委托自定义了事件参数LiggerEventArgs,将用于在客户端与服务端进行消息传递。我们不是要

WCF 项目应用连载[9] - 契约中的委托 & 事件参数处理

才能看到吗…和你想的一样。我们在这儿已经提前出现了，第9节可能要来这儿找答案了。。呵呵。。。先暂时把这问题放下。以后再解释。。。

不过有一样事件你可能想到了。Lig到现在为止可能不会再有什么升级了。这节我们讲到的是升级Lig服务，形成一个完善的Lig版本。在这儿，你能看到结果了。。。

public interface ILigger
{
bool ConnectStatus { get; }
int ClientID { get; }
bool SubscribeOnlineEvent(EventHandler onlined);
bool UnsubscribeOnlineEvent(int clientID);
void LigMessage(string message, int level);
void LigInfo(string message);
void LigDebug(string message);
void LigWarn(string message);
void LigError(string message);
void LigFatal(string message);
}

6.2 LigClient

这是我们现在写日志的状态：

ILigger ilg = new Ligger("Ligv","Ligv");
ilg.LigInfo("Your info lig here...");

有3个变化：

1)我们已以看不到原先在LigClient中出现的LigManager了，同时在LigClient/LigServer中已经看不到App.config了。取而代之的只有Ligger了。。

2) 现在写日志是不是已经很简单了。达到了我们原先的设想，让客户端变得更简单。。

3) 如你所看到的，我们多了LCommon库类项目。不见的App.config已经被封装了。封装到了LiggerBase



图6.2.1 LigClient

6.3 运行我们的Lig系统

其它的问题先不管了。我们看下我们的代码，运行你想运行的的客户端数，在LigClient中，我们写完日志让其离线。。。我们看下LigClient与LigServer控制台的消息变化。。

如图6.2。LigClient与LigServer间消息传递已经没问题了。。Lig系统运行了起来。。



6.3.1 Lig系统测试运行

6.4 还少什么吗？答曰：我还欠你一个解释。

还没完。。。我们是不是还有很多细节没有说啊。。。是的。。虽然Lig已经能很好的工作了。。但还有些，还是得交待下。。码字太累。。就简单点说。

6.4.1 有关Ligger

————————————————————————————————————————————

1) Ligger 用来创建LigClient。打开代码吧。你看到的是一个简洁的Ligger版本，为此，你也看到了，我们还添加了资源释放的接口Dispose。

2) Ligger实现类中没有任何质性的代码。在上面的图中我们已经看到了LiggerBase的存在，我们把创建WCF户端与写日志的逻辑代码全部写进了了LiggerBase。所以，这儿，Ligger只发生了对ILiggerBase接口的调用。

3) 前面我们不是在LigClient中看到LigManager了吗，现在不见了，去哪了？LigManager的代码已经变成了LiggerBase。又回到OOP的接口编程，所以，我们为LiggerBase设计了接口ILiggerBase用来对ILigAgent的进一步封装。而不只是一个LiggerBase类。

4) 有一点要明白，接口、抽象类永远不是必须的。只是我们要让这样的代码符合一些常用了软件设计模式，并且让代码变得更稳定。。

5) 至于一个项目中结构设计采用接口，还是用抽象类。。完全根据你的需要。。如果你能把设计模式在你的软件中用到至高无上的境界，我想你痛苦码农的日子就结束了。。。呵呵。。。够直接吧。。。



图 6.4.1 现在的Ligger

6.4.2 有关LiggerBase

————————————————————————————————————————————

不用我多说了，LigManager不见了，LiggerBase出现了，LiggerBase从LigManager的功能转化而来

1）去看下LiggerBase中的代码吧，其实不神密的，我们需要的是，看懂这样的设计思路。。就够了。。。

2）如果你曾仔细看过LigManager的代码，如果你想到要升级，可能就是LiggerBase下面这个样子。。。

是的，很多东西，不能什么都一步到位了。那样没劲也没挑战。。这点Patience我相信每个Coder都还是有的。。。不过，这个，倒不是必须有的。。。



图6.4.2 如你所见的LiggerBase

6.4.2 有关LCommon

————————————————————————————————————————————

其实。这儿。不好解释的。

1) LCommon的存在，想必大家都明白，身为一名这个世界中的Coder，如果没有自己常用的基础类库，并且能稳定运行的基础类库。。。我们很难想象你能在短时间内建立起一个稳定工程项目。。。

2) 除了架构软件本身，我们编写代码，基本每天都在跟数据打交道

3) 无论是xml、Access数据库、SqlServer数据库、Oracle、方法异步管理、事件管理、还是WCF通信、伊或是Remoting这些等等之类的东西，这些需求，还不足够你去建立一个自己的基础类库？

4) 如同Java中所谓的游戏引引擎，没有运行自己游戏的基础引擎，想想那些图形处理的事，你游戏如何能顺利转起来？。。。用别人的游戏引擎是需要Money的，你懂的。。

5) 在这儿，我们也需要一个引擎，能支撑Lig系统稳定运行，并能减轻Lig系统本身的负担的基础引擎，同时这个引擎还能应用于其它的项目而不是一个简简单单的Lig系统的应用。在这儿，你看到的不是LigCommon，是LCommon，想必已经知道答案了。

一个原因，我不想把自己的代码圈在这个小小的Lig系统内，我想在Lig系统之外用LCommon

L - 《死亡笔记》 中的那个绝顶聪明的家伙。。。这个字母，在这儿，用来纪念他。。。

我想这个LCommon也要够聪明。。。不过，话说回来，这儿，L代表你想用有任何想用的名字 ，我为什么没搞个XCommon这类。。这太难看了。。呵呵。。打住吧。。

6.5 好了

————————————————————————————————————————————

好了。到这儿。欠的这个解释，还完了。这节就结束了。你可以好好研究下 Lig的工程代码了。。或者运行它。。看到那一行行从控制台中输出的数据。。我想，我的时间，对WCF解释的时间差不多够了。。留点时间来做其它事吧。。。

很快我们要讲

WCF 项目应用连载[7] - 绑定、服务、行为 大数据传输与限流 - 上

前面我们看到了App.config。我们还欠对App.config的另外一个解释。。

是什么呢？ 看下节吧。。。。

本节提到的源代码下载：

————————————————————————————————————————————

WCF 项目应用连载[6] - 升级Lig服务 - 设计ILigger 构建一个完善的Lig版本 C#源码.rar

————————————————————————————————————————————