由于框架中对数据上下文（ef连接对象）在数据层进行了缓存处理，在后续的开发过程中总是会出现许多莫名奇妙的错误，比如：EF常见的报错，百度一搜一大把的那种、明明修改成功了，再次查询后却是修改之前的状态等等一系列问题。出现这样的问题，我花费了大量时间去找资料、请教前辈来解决。在搞明白基本原理的前提下，后续几个迭代开发版本中，慢慢调整框架使他更适用。
挖的第三个坑【最求高大上技术（不是特别熟悉的技术）有时候并不能有效解决问题，往往还有可能存在风险】
数据层核心就是EF这里我对其进行了简单的二次封装比如（增删改查），关键点就是微软推荐我们先把数据查询出来，再进行数据的更新。但是实际使用的过程中发现这样效率并不是很高，而且生成的Sql不够简洁，比如一个表多大上百个字段时，我只想修改一个字段，ef生成的sql脚本确实更新所有字段。基于以上的分析，对ef拓展了很多实用的方法，以至于到现在，这些方法都是必不可少的核心。
写了个辅助程序，让实体类能够自动加载数据库中的字段注释。虽然是个小东西，但是能省下非常多的时间，留下更多的时间去做更有意义的事。
数据库
数据库是重中之重，软件设计的好不好就看数据库了，有时候会多加一个冗余字段你会能够让你少写很多代码，能够大幅提升系统性能。在实际经验下发现，综合考量下来遵循范式设计的系统要比不遵循范式设计的系统就性能和用人方面而言，相差很大。其实很多时候，记住一句经典的话“把数据库设计的和excel一样！”虽然这样并不是很科学，也许这样设计在学校里或其他公司中会成为笑柄，但是实际开发过程中的经验所得，确实是如此。简单的设计会免去你很多烦恼。相比较老软件而言新架构的大变动如下：
数据库主键的技术选型，sql标准主键3种方案：1.guid类型（优点：全球唯一，速度快，缺点：占资源，冗长，不利于索引维护）；2.自增（优点：自动编码省心，缺点：主键自增的特性 数据迁移可能会有麻烦）；3.用户自定义（注意不要重复，自己定义规则）。我们选用的是用户自定义，采用的bigint也就是长整型做主键，主键统一为18位。用的是SnowFlake，我自己给他起了个别名叫“分布式id生产器”，其实这个方案是大哥极力推荐的，但是实际使用中还是面临许多问题，首先看他名字就知道不简单。既然主键在客户端生成那么他的原理还是先有客户端请求服务才能拿到一个可用的主键，而SnowFlake通过机器码和数据中心2个产生支持多个服务器部署能够满足大并发。SnowFlake原理还是根据时间和那2个产生来动态生成主键的。仔细考虑后发现，多多少少会损耗性能的，至少需要网络传输呀。还有一个弊端就是分布式id生产器宕机会直接导致系统奔溃等等一系列的问题会暴露出来。但是幸运的是目前还没有发现这样的问题。原理图参见下图
默认数据表都应该含有的字段：租户标识、创建人、创建时间、修改人、修改时间、逻辑删除标识、备注。最初除中间表外我们规定每个表都应该还有这几个字段。基本每个字段都是比不可少的主要用于数据追溯，如客户发现数据不对了找到软件公司，软件公司应能够做到数据被修改原因的追溯，从而规避问题，将问题放到指定人身上去。能够知道最后是谁动数据的。逻辑删除用于用户误删除数据恢复。然后在后续的开发过程中发现会有同一人修改相同数据，这就没法保证数据的一致性，由于考虑不周加上自己的懒惰想当然的用修改时间来控制，前期没问题，很顺利，但是忽略了一个细节就是修改时间只是用户对数据进行修改时才会改变，那用户不修改数据，数据由于其他模块导致变动版本怎么控制？我们发现这个问题时，产品已经上线了。最终不得不把每个表额外加上一个标准字段版本号，这样才从根本上解决了问题。
挖的第四个坑【不要由于偷懒而忽略一些潜在风险，时间会将问题慢慢放大，如果不及时修改，可能导致产品研发失败】