QBlog

开篇闲话：

一：CYQ.Data 数据框架中的AOP思路简述

1：关于最早期CYQ.Data数据框架实现AOP的思想文章，见：AOP 你想干什么 IOC 你服务什么

2：简单的再描述一下：

详情代码可下载：CYQ.Data V3.0 免费开源版本。

二：QBlog数据库的决择

首先：秋色园主体数据库是Access，当然是近乎每个表1个数据库，因此，是多个access数据库。

然后：秋色园再伴随着“文本数据库”，来分压一些简单读写的数据。

最后：决择是SQLite数据库，以分压用户的文章压力（没事多体验下其它数据库）。

目前秋色园的内存情况是：VPS总体是512M内存。

剩下渣都没的剩了，连“爱说说”也因内存不足，暂时停掉了，当然不可能选用其它大型数据库了。

三：实际场景的考虑

秋色园是一个多用户博客，而博客系统，每一个用户的数据，基本上是相互独立的，简单的说：多用户可以化整为0，变成无数个单用户博客，然后无数个单用户博客，组合起来，就变成多用户博客。

曾经有这么一种设想：

想的有点多，回到正常的思路上考虑：

想归这么想，总会带来一些问题的：

1：数据库文件会不会产生太多？

其实也不多，十万个文件不算啥，按下日期、用户ID、哈唏、用户名等多种方式分布到不同文件夹下，一个文件夹也顶不了多少个文件。再说，有10万用户你都超越博客园了，估计开始偷笑了。

2：聚合内容怎么办？如网站首页聚合多个用户的文章显示？

这个没啥，因为除了每个用户独立的数据库文件，还有总的access数据库，聚合时读access即可。

3：这么说数据变成一式两份？

这个没错，是成两份了，不过目前策略，文章的内容(数据比较多）独立仅1份，因此占不了多少空间。

4：两个数据库，如何同步？同时写两份？

写两份是要，当然就不可能同时写了，因为同时写，对原来的access还是存在多用户并发操作，具体看下面的详情。

5：这样系统不会变的很乱吧？

“最后的AOP策略”以插件的方式处理这种问题，一插，搞定，一拔，还是正常的，所以对系统完全不影响。

四：最后的AOP策略的实现

1：创建新的项目，开始AOP切换项目。

由于AOP内置以反射调用DLL插件式注入，因此原有逻辑代码不改变，只要开新的项目处理即可。

然后配置文件配置一下相关的调用即可，各家实现不一，仅供参考说明：

2：为每个用户创建SQLite数据库

主要为三步：

以下为代码节选：

再接下来，就是处理各种“增删改查”的数据库同步问题：

3：增加数据的处理流程：

先看一个插入代码AOP的伪方法：

这果按这原有的AOP逻辑，将造成一种情况，写完SQLite数据后，同时又将继续写Access数据库，这明显是有问题的，假设多个用户发布文章，虽然SQLite是写在不同的数据库，可是同时写主数据库Access，必然又出现并发4K问题。

为此，对于主Access，必须使用新的方式来实现，再借文本，定时插入：

实现原理：

简单的说：把并发写Access数据库，变成队列式，1条接1条的插入，如此一来，并发写就解决了。

为了适应这种变化，原有的AOP必须稍的改进，AOP.Begin方法需要增加返回值，以便作为条件，可以跳过下面的执行，为此，增加了返回值的枚举：

有了返回值，插入后，跳过Access的插入执行，返回成功即可。

参考代码：

4：删除数据的处理流程：

当用户操作删除文章时，默认Begin不执行，先走原来流程，删除主表，再从End事件删除SQLite表。

参考代码：

5：修改数据的处理流程：

参考代码：

6：数据的查询功能：

根据条件判断，如果是单用户的数据，直接Begin方法查完SQLite后返回即可。

示例的查询代码：

至此，整体的最后的AOP策略处理就基本结束了。

总结：

到此，秋色园技术原理系列估计就写到这里了，本系统的技术内幕，基本也外露完了。

感谢网友对本系列的支持！！！