身份和已计算之间的区别是执行的SQL命令的行为。如果属性是身份 EF会选择插入后的值，并返回到你的应用程序。如果属性是已计算 EF都将插入和更新后，选择相应的值，并返回到你的应用程序。

编辑：

StoreGeneratedPattern.Identity 是不相关的身份在数据库中。你并不需要有身份的数据库，你可以设置一些不同的techinque（默认值GUID或触发）ID，但你仍然需要 StoreGeneratedPattern.Identity 来获得价值回到你的应用程序。

在你使用身份或已计算 EF将始终遵循每个插入或更新与选择的数据库生成列。它不能没有它的工作。这些命令在单个往返执行数据库所以几乎没有性能影响。

I am interested in what is the most performant way for StoreGeneratedPattern.

In past I was used to let the DB generate the ID for me but I was wondering if there is any advantage in setting

StoreGeneratedPattern = None 

instead of

StoreGeneratedPattern = Identity

I am not even sure what happens when I set it to Calculated.

Any recommendations? Is there any nice article related to this because msdn is not very explanatory. I am using mostly ints with few GUIDs in my schema.

Check my blog post about StoreGeneratedPattern. It explains some differences between Identity and Computed. When using StoreGeneratedPattern for ID (PK) the correct option is None if you assign ID in the application or Identity if you assign ID in DB. Computed option is "invalid" because this option is used when value is changed during each entity persistence (also in updates) and it is not the case of ID.

The difference between Identity and Computed is behavior of executed SQL command. If property is Identity EF will select the value after Insert and return it to your application. If property is Computed EF will select the value after both Insert and Update and return it to your application.

Edit:

StoreGeneratedPattern.Identity is not related to Identity in DB. You don't need to have Identity in DB and you can set ID with some different techinque (default value for guid or trigger) but you still need StoreGeneratedPattern.Identity to get value back to your application.

Once you are using Identity or Computed EF will always follow each Insert or Update with Select for db generated columns. It can't work without it. These commands are executed in single roundtrip to database so there is almost none performance impact.