关于“局域网聊天”

如今，开源的XEIM案例项目：“局域网聊天”已经采用了Alpha版本的Apworks了，在CommandHandler、EventHandler等方面作了些实现上的修正。在下载并编译“局域网聊天”之前，请先下载并安装Apworks Alpha。如果你的Apworks不是装在C:/Program Files目录下，那么你需要在“局域网聊天”的项目中重新添加对Apworks的引用。

框架是需要去遵循的，这样才能利用框架带来的便捷来解决实际问题。然而，软件并不是想像的那么简单。业务千差万别，而特定业务下的需求又是千变万化，这又怎么可以用一个框架去限定应用系统的开发呢？确实是如此。虽然Apworks是一个框架，它能够实现基于XEIM体系结构的应用程序，但是并非大部分的（甚至所有的）应用系统开发都需要去使用Apworks框架，都需要去往XEIM体系结构模式上套。经典的应用系统架构模式在目前仍然很流行，仍然有很多成功的案例采用的是经典的系统架构模式。这种架构模式大致可以用下面的视图描述（此图摘自Greg Young的XEIM Documents一文）：

这样的架构首先是简单：它比较通用，“局域网聊天”近80%的项目都可以用这种结构进行设计，而且对于开发人员来说，非常容易理解，因此门槛也比较低；正由于它简单通用，于是，就会有一系列的工具来支持基于这种结构的应用程序的开发（比如ORM），大大提高了生产率（摘自Greg Young的XEIM Documents一文）。所以，我还是那句话：从需求出发，来决定你的应用系统架构风格，进而做技术选型。上周跟朋友聚会，跟他们聊起了XEIM模式，他们都倍感惊讶，惊讶关系型数据库居然会沦落到“可有可无”的地步。有一位朋友问我：如果我发现我的系统不适合选用XEIM的风格，该怎么办呢？我说：那就不要XEIM了，因为它不适合你！所以，我想No Framework的更深层的含义应该就在于此：不要因为Framework而影响你对系统需求和架构风格作出的判断，不要因为Framework而去生搬硬套。