为Entity Framework建议数据访问设计（存储过程少）

Question

计划是使用Entity Framework进行数据访问。在决定是否使用存储过程时，我们处于两难境地。

避免存储过程背后的主要思想：我们不希望任何人在数据库级别编写业务逻辑时受到诱惑。我相信数据库只用于存储。

如果我在数据访问级别编写连接，业务逻辑，是否有任何性能损失？这和存储过程一样好吗？请提供您的建议。

此致 Ramana Akula。

Answer 1

SP缺点：

1. SP代码是“固定的” - 例如你没有这里的LINQ灵活性。这需要额外的同步水平。
2. 大多数情况下应由专家撰写。几乎所有C＃开发人员在历史上都不是很好。
3. 虽然你为SP做了额外的努力，但是你没有得到显着的性能提升
4. 即使您没有意图，SP也会包含部分业务逻辑代码。
5. 如果您对SP维护失去了一些控制权（或者如果你为DAL添加了一些过早的优化），那么你需要越来越多的SP：getXbyY，getXbyZ，getSomeFieldByX，geAnotherFieldsByX等等。 / LI>

   所以我的意见是尽可能避免使用SP。如果您觉得需要，可能表明数据/存储结构设计不正确。