【问题标题】：Suggest data access design for Entity Framework (stored procedure less)建议实体框架的数据访问设计（少存储过程）
【发布时间】：2012-03-03 16:26:38
【问题描述】：
计划是使用实体框架进行数据访问。我们在决定是否使用存储过程方面处于两难的境地。
避免存储过程的主要思想是：我们不希望任何人试图在数据库级别编写业务逻辑。我相信数据库只是为了存储。
如果我在数据访问级别编写联接、业务逻辑，是否会对性能造成影响？这和存储过程一样好吗？请提供您的建议。
问候，
拉玛那阿库拉。
【问题讨论】：
标签：
entity-framework
database-design
architecture
entity-framework-4.1
【解决方案1】：
SP缺点：
- SP 代码是“固定的” - 例如你在这里没有 LINQ 的灵活性。这需要额外的同步级别。
- 在大多数情况下应由专家编写。从历史上看，几乎所有 C# 开发人员都不是很擅长这一点。
- 尽管您为 SP 维护付出了额外的努力，但您并没有获得显着的性能提升
- 即使您没有意图，SP 也会包含部分业务逻辑代码。
- 如果您对 SP 维护失去了一些控制（或者如果您要向 DAL 添加一些过早的优化），您将需要越来越多的 SP：getXbyY、getXbyZ、getSomeFieldByX、geAnotherFieldsByX 等。
所以我的意见是尽可能避免使用 SP。如果您觉得需要一个，这可能表明数据/存储结构设计不正确。