背景：
前不久和阿里的一个技术总监风动聊的时候，他问了这样一个问题：说说你框架的设计思路和优点？
话说，这个问题，5年前开始就一直经常出现在眼前，可我从没认真为它找出过答案！
于是，夜深深，我躺在床上，用笔记本，一边思考，一边打字，试着找寻！
这些年来，我的框架或作品，都快凑满十二个了，每个单独都可以说上好几天。
但如果时间只有半小时，我要怎么介绍呢？介绍哪些呢？
出现在脑海里的框架有三个：CYQ.Data、ASP.NET Aries、Taurus.MVC。
大概是因为近期的精力都在这上面吧的吧（如当年我精力花在Ｑblog一样吧）。
说说你框架的设计思路？
框架的设计思路？哪个框架？我自己挑一个？
如果要讲Aries或Taurus，就必须讲CYQ.Data，因为它们都是基于CYQ.Data的存在而存在的。
所以问题就变成回答：说说你CYQ.Data框架的设计思路？
我感觉很难回答这个问题，内心也能感受到一丝抗拒这个问题的想法？
框架是漫长的岁月演进重构而来的，最早期的思路是这样的：
构造一个简单的MDataTable体系，传进一个表名，根据数据库链接拿到表结构，再根据行的列构造出ＳＱＬ语句执行，把数据读到ＭDataTable返回。
以上一句概括了最早期的思路，但没有设计，简单并不亮。
如果要说说最新版本的设计思路，我想不到该怎么表达，因为重构的次数太多了，几百上千次了，太多细节，每个细节都独立带有它自己的设计思维。
就像腾迅最早也只是ＱＱ发个消息，现在发展到生态圈，你说人家是怎么设计现在的帝国的？
也许，只是做着做着，就这样子了〜〜〜才是答案吧。
好吧，设计思路回答不上来，那就讲讲框架有什么亮点吧？
我了个去，又是这个问题，一个在我内心深深留下伤痕的问题。
我曾经用尽洪荒之力写过一篇文章，来介绍框架的优势，可是我现在记不起来了！
只能忘掉文章，重新思索了：
1：框架支持多数据库。（旁白：支持多数据库的框架到处有吧）
2：嗯，重点框架能把数据从一种数据库转向任意一种数据库（旁白：项目里需要混合数据库的场景太少，这功能没啥感觉）
再想想：
1：框架的缓存集成了Memcache、Redis（旁白：集成不是很简单的事情么？）
2：嗯，但客户端没有引用第三方，都是自己写的，Json解析都是自己写的（旁白：只能说技术好，但功能不算亮点）
再想想：
1：框架实现了自动缓存。（旁白：缓存有啥特别，Hibernate也有二级缓存，说说你它有啥区别？）
2：嗯，Ｈibernate的二级缓存没法自动失效，因为它的失效策略没法处理自定义的sql语句（旁白：你是怎么控制的？）
3：嗯，我是通过分析执行的ＳＱＬ语句，得到语句所关联的表，通过表这个维度来控制的（旁白：那不会产生很多缓存无效问题？表的修改无处不在，能控制到行么？）
4：不能，但可以控制列，嗯，所以我还设计了，可以指定忽略哪些字段的更新不触发缓存失效，也可以指定哪些表不需要缓存（旁白：如果不在ＳＱＬ层面，在应用层面如何控制缓存失效？）
5：在业务代码控制吧？或者通过ＡＯＰ统一控制？（旁白：不是我想要的答案）
6：也可以通过数据库来触发缓存失效，ＭＳＳＱＬ就有提供缓存依赖（旁白：具体怎么实现呢？）
7：微软的直接调就好了，具体原理是通过触发器把修改的数据写入指定的表，再通过定时器扫表。（旁白：也不是我想要的答案，还有其它答案么？）
8：没有了，你说说（旁白：以前好像讲过，现在想不起来了，说说你那个Aries框架的亮点吧）
半小时已经差不多了，亮点依旧没有被感觉出来〜〜〜
Aries的亮点？我还没恢复洪荒之力再给它写一篇框架的优势篇呢，该怎么介绍？
1：嗯，框架就是传一个表名，就可以自动生成增删改查导入导出，还自定义了一套简单的前端语法，结合后端很容易开发（旁白：不知道你说什么，还是闲聊一下其它的吧.....)
－－－－－－－－－－－－－－－－－－－重新思考，若只有半小时，该怎么介绍框架－－－－－－－－－－－－－－－－－
介绍：CYQ.Data的亮点
思考了1天，发现亮点功能太多：元数据缓存、AOP、UI交互、调试、模板引擎、Json工具、DB工具、分布式缓存、批量、内存表、文本数据库、防SQL注入、多数据库转换等。
如果一个一个介绍及聊其技术细节，十年的成果，讲三天三夜也没完！
可如果时间有限，只能讲三个，那我必须对其进行抽象总结。
经过反复的思考，忽略人有我优，只选人无我有的角度，总结了三个核心：
1：自动缓存：抗并发。
对于中小型项目，自动解决抗并发问题，提升网站性能、简化代码，精简架构！
对于大型的高并发大数据量的复杂业务，缓存还是要进一步细化控制命中率。
2：水平扩展：零编码。
Ａ：单种类数据库扩展到多种类数据库。
Ｂ：单机缓存扩展到分布式缓存。
Ｃ：单数据库扩展到集群数据库（读写分离）。
通通只要简单追加配置即可。
3：数据结构：自由转。
Ａ：Json、Xml、实体类：可互转。
Ｂ：泛型、字典、集合，与Ａ类：可互转。
Ｃ：数据库表与Ａ类、B类：可互转。
感觉这样抽象总结后，应该半小时就可以介绍完重点了，哈〜〜
至于星座十二宫框架：ASP.NET Aries（白羊）、Taurus.MVC（金牛）、还有在重写中的第三星座Ｇemini.Workflow（双子）。
该怎么抽象其介绍，需要多几个夜晚待我仔细想想〜〜〜
总结：
通过本次思考，意识到两个问题：
1：曾以为好的作品，不需要去告诉用户怎么好，用了自然知道好在哪里。
首先天真的假设了用户首先会用，其次假设了用户会口口相传。
2：曾经以为经验丰富就可以Hold住一切，自由发挥。
对于经常出现的问题或场景，与其每次都随机产生答案，不如深度的思考总结出一种较优的固定答案。
最后，不知道用过框架的小伙伴们是什么感觉？