前方：
其实完成这个功能之前，我就在思考：是先把想法写了来，和大伙讨论讨论后再实现，还是实现后再写文论述自己的思维。
忽然脑后传来一个声音说：你发文后会进入发呆阶段。
所以还是静下心，让我轻轻地把代码撸完再说。
最近这几天，自己在大脑里演练过各种技术难点，解决方案，推敲了各种该解决的问题，觉的差不多了，才决定撸码。
忽然发觉，原来代码是可以写在大脑里的。
要是你看到一个员工坐着2天没写一行代码，说明人家是高手，正在大脑编程。
好，不扯，回正文！
传统ORM的二级缓存为何失效？
有些ORM会提供：如Hibernate。
有些不提供：如EF，不提供是因为知道提供了也没啥鸟用，因为：
1：你不能强迫一个项目全部用单实体编程，多表时，用户更偏向于执行SQL语句。
2：没有分布式缓存做为基础，解决不了多应用程序部署的缓存策略问题。
因此：
1：若控制不了整个项目用户的SQL语句，单机的搞不了。
2：没有分布式缓存做基础，分布式的都搞不了。
这也是为啥EF一直不提供，是因为看到Hibernate虽然提供但并没多大卵用的原因吧！
疑惑数据库已有缓存，为何框架还要造孽？
主要原因：
1：数据库从请求到建立缓存，需要时间（框架缓存可以减缓数据库缓存失效时压力)
2：数据库是有链接数限制的，不可能允许大量并发的直连，需要外界分压。
3：数据库的缓存是单机性。
4：数据库发数据往服务器的时间比本机缓存的长。
自动缓存设计前的一些思考：
1：一开始我思考的缓存策略，是细化到行或列，于是了解数据库自身缓存后发现数据库目前也只是做了以表为单位。
2：MSSQL是有提供SqlDependency的缓存依赖项的，它可以从数据库层面通知你的数据何时失效。
3：但是SqlDependency和SqlCommand依赖太深，无法在所有数据库层面通用。
4：SqlDependency的缓存依赖只能在本地缓存。
5：其它数据库不支持依赖通知。
6：所以方案只能通过全局执行与分析，来处理缓存及失效策略。
7：单机时：全局拦截分析，如何分析出表？
8：应用分布式时：缓存及时失效？
9：用户直接修改数据库时：缓存如何失效？
还有好多好多问题，一直在思考......
缓存什么？
1：缓存单个对象时，是直接存档对象的，Cache返回时会根据本地或是远程选择是否Clone返回。。
2：缓存列表时：只存档字段类型仅包含：（数字、布尔、字符、时间、GUID）的字段，并转成Json字符串存档。
技术细节：
A：一个对象存档在本机时，存档的是引用（可能出现误写操作）；存档在分布式时，存档的不是引用，这会在使用时出现不确定性。
B：大对象的存档，在缓存来去间需要序列化和反序列化，性能上降低很多。
因此：将列表转成Json存档，拿到时再还原，可以同时解决A和B的问题。
简单的说，如果对象有长字段，或者有二进制数据，是不会被缓存的，所以MSSQL的Timestamp字段就不要用了；
如果要用：AppConfig.DB.HiddenFields="字段名"，把它隐藏了也行。
缓存时间？
考虑到通常访问量低时都是在中午和晚上的时间，因此，将缓存的对象的时间随机分布（早上的分布在中午失效，下午的分布在晚上失效）
考虑到分页时的查询，通常都关注前面几页，因此前面几页的数据，时间如上的时间段分布。
分页后面的数据，只默认2分钟的缓存时间。
其它规则有待讨论......
缓存多大？
1：在单机状态，检测到内存的可用比例低于15%时，则不再接受缓存。
2：在分布式缓存状态，暂时有多少扔多少。
缓存如何失效：
1：拦截请求：（包括（MAction）增删改查+（MProc）执行自定义语句+（MDataTable）批量方法）
2：分析语句的关联表（单表的可以拿表名，视图的拿关联结构涉及的表名，存储过程（目前没法），自定义SQL（语句分析出表名），批量（直接拿表名）
3：技术难点：如何从未知的SQL或视图中准确的分析出所有关联的表。
4：缓存失效：执行以下方法应该失效：增删改，执行ExeNonQuery，批量语句。
5：技术难点：
1：对于视图（关联了多个表，如何根据一个表名，关联到相应涉及的视图语句失效？）
2：对于分布式的应用，A服务更新，如何B服务器也失效。
如何处理修改频繁的表：
1：一开始想增加配置，让用户设置不参与缓存的表，认真思考后，发现根据缓存失效的时间和次数，可自动分析判断一个表是否修改频繁。
2：表操作相关增删查时，该表被置为失效（相关缓存会被移除），此时设置好时间间隔（6秒），在此时间段对该表相关的不缓存，同时提交的缓存删命令也可以无视。
3：对被分析出为修改频繁的表该如何处理？延长相应的不缓存时间，或是？？还需要思考！！！
缓存失效的粒度能不能小？
1：目前的失效，和数据库一样，是以表为单位的。
2：对于插入操作，不会影响某一条数据的读取（所以单条数据的查询，是不应该受到插入操作的影响的）
3：还有其它情形是必然不会影响的？
框架有自动缓存，业务需不需要缓存？
1：数据库有自动缓存，框架的也可以自动缓存。
2：框架有自动缓存，同理业务也可以有缓存。
框架能处理的粒度是有限的，不能细到具体的行或列的缓存级别，因此在业务复杂和并发到一定量后，业务缓存是必要的。
数据库有缓存，业务也可做缓存，为何还思考往框架增加自动缓存？
1：数据库的默认缓存是固定的，需要配置，各种数据库环境不一致。
2：数据库链接池默认是固定的。
3：业务加缓存的事，往往是后期的动作。
现另一个现状是：
1：.NET 群体，存在很多初中级的开发人员，这部分人员的技术成长相对较慢，对缓存或性能调优并不熟。
2：国内有很多的中小网站，默认都抗不起并发，攻击成本很小，几百上千个并发就可以挂你站了。
因此，既然有现实的问题，就可以有对应的解决方案。
V5框架此功能的出现，就是为了从基础层面统一解决这些问题。
只有当.NET行业不在有慢网站的存在，整体提升档次了，有良好的口碑，才会引进更多的BOSS选用 .NET，大伙所期待的.NET春天也就近了。
V5的目前解决的问题：
总体而言，要实现这个功能，核心要解决以下问题：
下面我来将技术一点一点出卖：
5：AOP拦截问题：
首先，要实现这功能，就得全局拦截，扫荡过源码或用过V5的同学，听说过框架本身就有AOP的吧；
其次，得改造这个AOP：框架默认有一个空AOP，当外部有AOP装载的时候，会替换掉这个空AOP。
要实现这个自动缓存：本想在空AOP里实现，放着浪费，但若用户自定义的Aop被装载，又会被替换掉，走不通...
方案想了三四个，思考了三四夜，最后还是在撸码时才确定了现在的模式（这个告诉我们，想的差不多了就该撸码了，要100%想通再撸不太靠谱）：
于是，我这样做了：
原有的Aop，改名成InterAop，不过是挂名的，因为它没有继承IAOP接口，而且从原本的单例变更成多例模式。
这里可以贴两行代码，意思是：在Bengin和End方法调用了外部AOP的接口，并根据外部AOP的状态决定后续的执行流程：
完整的源码你们自己SVN了：https://github.com/cyq1162/cyqdata.git
public AopResult Begin(AopEnum action)
{
AopResult ar = AopResult.Continue;
if (outerAop != null)
{
ar = outerAop.Begin(action, Para);
if (ar == AopResult.Return)
{
return ar;
}
}
if (AppConfig.Cache.IsAutoCache && !IsTxtDataBase) // 只要不是直接返回
{
isHasCache = AutoCache.GetCache(action, Para); //找看有没有Cache
}
if (isHasCache) //找到Cache
{
if (outerAop == null || ar == AopResult.Default)//不执行End
{
return AopResult.Return;
}
return AopResult.Break;//外部Aop说：还需要执行End
}
else // 没有Cache，默认返回
{
return ar;
}
}
public void End(AopEnum action)
{
if (outerAop != null)
{
outerAop.End(action, Para);
}
if (!isHasCache && !IsTxtDataBase)
{
AutoCache.SetCache(action, Para); //找看有没有Cache
}
}
代码最后很少，但没想出来之前，２天都搞不定。
１：基础单表、视图操作
A：单表，这个是最简单的，传递进来的就是表名；
B：视图，这个麻烦一点，传递的是视图名；
于是，如何从视图获取相关参与的表名？你现在应该不知道，我来告诉你吧：
DBDataReader sdr=.... DataTable dt = sdr.GetSchemaTable();
这条语句，可以通杀所有的数据库，不用去N种数据库里搜各种元数据藏在哪了！！！
2：多表SQL语句操作：
对于SQL语句，可以用上面的方法，执行一个DataReader再拿，但我弄了一个简单的方法来找关联表：
internal static List<string> GetTableNamesFromSql(string sql)
{
List<string> nameList = new List<string>();
//获取原始表名
string[] items = sql.Split(' ');
if (items.Length == 1) { return nameList; }//单表名
if (items.Length > 3) // 总是包含空格的select * from xxx
{
bool isKeywork = false;
foreach (string item in items)
{
if (!string.IsNullOrEmpty(item))
{
string lowerItem = item.ToLower();
switch (lowerItem)
{
case "from":
case "update":
case "into":
case "join":
case "table":
isKeywork = true;
break;
default:
if (isKeywork)
{
if (item[0] == '(' || item.IndexOf('.') > -1) { isKeywork = false; }
else
{
isKeywork = false;
nameList.Add(NotKeyword(item));
}
}
break;
}
}
}
}
return nameList;
}
有可能会找多，找到后，再过滤一下名称是不是数据库里的表就可以了。
3：直接操作数据库
一开始设置的思维，是动态创建一个表，字段大概是这样的：
表名 更新时间
然后如果手工操作数据库，可以手工更改时间，也可以用触发器引发这里的更新。
然后后台线程定时扫这个表，就知道有没有表被更新了。
不过--------V5目前并木有实现它，只是开放了一个接口，可以让你在代码里调用移除缓存。
这个方法就是：
public abstract partial class CacheManage
{
/// <summary>
/// 获取系统内部缓存Key
/// </summary>
public static string GetKey(CacheKeyType ckt, string tableName)
{
return GetKey(ckt, tableName, AppConfig.DB.DefaultDataBase, AppConfig.DB.DefaultDalType);
}
/// <summary>
/// 获取系统内部缓存Key
/// </summary>
public static string GetKey(CacheKeyType ckt, string tableName, string dbName, DalType dalType)
{
switch (ckt)
{
case CacheKeyType.Schema:
return TableSchema.GetSchemaKey(tableName, dbName, dalType);
case CacheKeyType.AutoCache:
return AutoCache.GetBaseKey(dalType, dbName, tableName);
}
return string.Empty;
}
}
4：跨服务器操作
这个本来是简单的，后来又想麻烦了，因为要兼顾性能问题，缓存移除可能会频繁的问题。
后来，通过增加了缓存类型，来识别本地缓存或分布式缓存，来区别写代码：
private static void SetBaseKey(string baseKey, string key)
{
//baseKey是表的，不包括视图和自定义语句
if (_MemCache.CacheType == CacheType.LocalCache)
{
if (cacheKeys.ContainsKey(baseKey))
{
cacheKeys[baseKey] = cacheKeys[baseKey].Append("," + key);
}
else
{
cacheKeys.Add(baseKey, new StringBuilder(key));
}
}
else
{
StringBuilder sb = _MemCache.Get<StringBuilder>(baseKey);
if (sb == null)
{
_MemCache.Set(baseKey, new StringBuilder(key));
}
else
{
sb.Append("," + key);
_MemCache.Set(baseKey, sb);
}
}
}
6：缓存失效问题
这个问题，流程本来很简单的：
但思考到Cache多，而且分布式时，返回会卡，所以删除Cache操作就变成线程处理了。
后来为了避免线程多开，又把类改成了单例（一开始是多实例的）
现在，又把这线程的线程开启，放到LocalCache里和另一个线程作伴了，然后这个单例类又变更成了静态类。
V5框架怎么使用这功能：
升级版本到最新版即可！
总结：
1：没有这个功能之前：框架解决了三大问题：编程架构的统一（自动化）、数据库压力（读写分离）、服务器压力（分布式缓存）。
2：此功能的存在：是针对从基础层面提升行业项目的整体水平。
3：最近大脑有点发春，一个个创新Idea不断的从我大脑冒出来，折腾的我好累：
要思考架构、落实框架代码、要写文分享，写框架Demo、群里解答。
4：开源不赚钱，又投入这么多精力，只能把它当理想了，希望它有天成为.NET项目的标配数据层。
5：我博客是有打赞插件的，哈。