发布Apworks应用开发框架（Alpha版本）
Tiny Library CQRS的介绍文章有好些日子没有更新了，因为最近一直在忙着发布Apworks应用开发框架。原本打算在2011年1月1日发布，以迎接新年的到来，后来确定了还是在2010年12月31日发布，就算是给过去的一年做个留念。哈哈。
一直关注我的博客的园友都知道，之前我的一些领域驱动设计的案例，都是以Apworks为基础的。由于时间关系，Apworks一直没有一个固定的版本，所以在那些案例中，我都是将Apworks的程序集加入了案例的发布包里。现在，终于能够为Apworks整出一个“可用”的版本，并将其发布到了codeplex上，地址是：http://apworks.codeplex.com。版本：Alpha（v1.0.4016.23016）。有关Apworks的所有文档，我都上传到了http://apworks.org/documents.aspx。不过目前只有一篇文章，就是：Walkthrough - Building Applications with Apworks，它也同时被包含在了Apworks Alpha版本的安装包里。
先决条件
如果你希望使用Apworks进行开发，请确保你的机器满足如下先决条件：
- .NET Framework 3.5 SP1
- Visual Studio 2010
- Microsoft Patterns & Practices Enterprise Library 5.0 (April 2010)
- Microsoft SQL Server (Express) 2005或更高版本
下载Apworks Alpha安装包
请点击下面的链接下载安装包，在下载开始之前，你需要同意LGPL 2.1许可证协议，否则下载不会继续。
单击此处下载Apworks Alpha 1.0.4016.23016
关于Alpha版本
在Release Notes里面，我列出了Alpha版本功能的缺失点，虽然Apworks没有这些功能点照样能够成为一个独立而且完整的组件，但它目前仍然不适于用在实际的项目开发中，尤其是那些非常关键的应用系统中。在将来的Beta版中，我会把功能缺失点加上，使其能够真正支撑一个应用系统的设计与开发。现在，我再把Alpha版本的功能缺失点介绍一下。
- Alpha版本仅支持Direct Message Bus，这种消息总线使用共享内存存储消息，因此，应用程序不得不将Command端和Query端设计在同一台物理服务器上（因为Command端需要向Query端的事件总线发布事件通知，而Direct Message Bus却不支持远程的内存操作）
- 事件存储与快照：Alpha版本仅支持基于SQL Server关系型数据库的事件存储与快照机制。当然，开发人员可以自己定制。快照策略也非常简单：每当事件存储去保存第1000个事件的时候，就会针对该聚合做一次快照。这个逻辑是被定义在SqlDomainEventStorage类的CanCreateOrUpdateSnapshot方法里的，而这个方法本来是定义在IDomainEventStorage接口里的。如果你希望使用Alpha版本的Apworks，并且需要定制快照策略，那么你可以继承SqlDomainEventStorage类，并重写CanCreateOrUpdateSnapshot方法。对于其他类型数据库或存储机制的支持，将在今后的版本中发布
- 查询数据库：目前也仅支持SQL Server
- 对象IoC容器：目前仅提供对Microsoft Unity的接口支持，下个版本中会支持Castle Windsor（不过这个优先级不是很高）
- PropertyBag仅仅支持非常简单的条件组合：aaa=xxx AND bbb=yyy。不支持OR，也不支持各种其它的不等运算符。打算在下个版本中用Expression替换掉
关于安装包
在制作安装包以前，一直在想，该用什么工具来制作安装包。InstallShield虽然强大，但是太繁琐而且不是免费的；InnoSetup也不贴心，与.NET整合不够紧密；于是选择了WiX。选择WiX的原因是：它是.NET下原生的安装制作工具，能够直接集成到Visual Studio里，而且小巧简单（注意：不是简洁！），此外，我们项目组也正好是用的WiX，正好拿来练手。当然WiX也有它的缺点：繁琐（需要手动维护XML文件，而且定制用户界面也不方便），编译速度也不是很快。不过它的小巧确实让人感到清爽。
关于Tiny Library CQRS
如今，开源的CQRS案例项目：Tiny Library CQRS（http://tlibcqrs.codeplex.com）已经采用了Alpha版本的Apworks了，在CommandHandler、EventHandler等方面作了些实现上的修正。在下载并编译Tiny Library CQRS之前，请先下载并安装Apworks Alpha。如果你的Apworks不是装在C:\Program Files目录下，那么你需要在Tiny Library CQRS的项目中重新添加对Apworks的引用。
No Framework！
框架是需要去遵循的，这样才能利用框架带来的便捷来解决实际问题。然而，软件并不是想像的那么简单。业务千差万别，而特定业务下的需求又是千变万化，这又怎么可以用一个框架去限定应用系统的开发呢？确实是如此。虽然Apworks是一个框架，它能够实现基于CQRS体系结构的应用程序，但是并非大部分的（甚至所有的）应用系统开发都需要去使用Apworks框架，都需要去往CQRS体系结构模式上套。经典的应用系统架构模式在目前仍然很流行，仍然有很多成功的案例采用的是经典的系统架构模式。这种架构模式大致可以用下面的视图描述（此图摘自Greg Young的CQRS Documents一文）：
这样的架构首先是简单：它比较通用，近80%的项目都可以用这种结构进行设计，而且对于开发人员来说，非常容易理解，因此门槛也比较低；正由于它简单通用，于是，就会有一系列的工具来支持基于这种结构的应用程序的开发（比如ORM），大大提高了生产率（摘自Greg Young的CQRS Documents一文）。所以，我还是那句话：从需求出发，来决定你的应用系统架构风格，进而做技术选型。上周跟朋友聚会，跟他们聊起了CQRS模式，他们都倍感惊讶，惊讶关系型数据库居然会沦落到“可有可无”的地步。有一位朋友问我：如果我发现我的系统不适合选用CQRS的风格，该怎么办呢？我说：那就不要CQRS了，因为它不适合你！所以，我想No Framework的更深层的含义应该就在于此：不要因为Framework而影响你对系统需求和架构风格作出的判断，不要因为Framework而去生搬硬套。
