时间戳、复杂类型、GUID自增长

GUID自增长

GUID用于当主建那是好处多多，但是和int不同。EF不会自动识别第一个为类名+Id开头或int类型字段 去设置自增长。尴尬的GUID怎么玩呢。。

Data Annation玩法

Fluent API 玩法

注：上面的设置好像没什么用，至少我是没跑起来。。。故而使用的是构造函数玩法。。。

时间戳

好处多多的东西啊，对于一些并发的业务来说建表的时候是一定要有这个的。但是某些原因….. 这就尴尬了 。。

最重要的一点是乐观锁，什么是乐观锁呢？

在并发的时候，A、B两个线程同时拿到一条记录然后进行更新再插入数据库。这样会导致A、B都成功了！对于一些抢单的来说这样是不可以的。乐观锁则是在第一次更新的时候把时间戳也更新一下。另一个线程更新的时候会判断当前的与表里的时间戳不一致的话。那就失败了。

Fluent API 玩法

下面开始模拟并发，aContext先拿到更改一下字段值，紧接着bContext也拿到了更新了一字段值并保存。这时aContext再去保存

后面执行，bContext的成功保存！而aContext则报错

 假如像我这种尴尬的情况，表已经这样了。应该怎么做乐观锁呢？可以使用 ConcurrencyCheck对某个唯一的字段进行注解，也可以达到控制并发的效果

复杂类型

随着业务的扩展，表中的字段自然是越来越多，实体越来越膨胀。想想这会带来什么后果？恶心的类，大多无用的返回值，结构不清晰。这些都是需我们去注意的。

这里假如项目第一版我们的用户只有Name字段，但是在第二版需要加上地址。那简单，直接在User类中直接加地址，但是上面说这样是不好的。我们应该去 "扩展"。那也简单，新建一个实体就是咯，然后在User中加入 属性。但是！这样会自动映射外建关系。这时我们就需要复杂类型了

　　复杂类型没有ID  //这里有些错误 [Table(xxx)] 是没用的。因为不是创建新的表

在User类中进行扩展

搞定后，再Update-DataBase 一下

额。。。这就尴尬了。怎么还是在一个表中？之前是我理解错了。我们代码中的实体膨胀问题是解决了但是表中还是并没有。这里我个人还是建议单弄一个表，把不属于表的"核心属性"放到扩展表中，这样也算不错吧。好歹代码中不是这么恶心了

EF-CodeFirst-2玩的嗨