针对存储过程的情况？

任何想法/有超过3000的存储过程的数据库上的评论查询/访问超过1,400表（过于归一化）。真的想要使用像Entity Framework这样的技术，最好是4.0，并从这些存储过程中获得业务逻辑？针对存储过程的情况？

，如果你决定要分享欣赏任何现实生活中的实际经验&反馈。这是我继承的一个数据库，并且真的觉得现在是时候为了更好的业务层而放弃存储过程了。

2010-06-22 baskint

它工作吗？你能保持它吗？有问题吗？有具体的担忧吗？没有特定的“问题”，就没有什么可谈的了。 – 2010-06-22 02:46:22

嗯，是和不是。每次通话都是一个短片。团队在印度，我们正在使用Team City来部署前端和后端（至少现在是分开的）。这是数据访问层中的.NET 1.1和.NET 2.0应用程序。数据表，数据行，ADO.NET，企业库等。真的很想将这些引入.NET 3.5世界，以供初学者使用。谢谢你的答复，斯科特。 – baskint 2010-06-22 02:53:04

哦，偶尔代码库会与存档的不同步，并成为一个麻烦。 DBIntegrations测试无法捕获这些测试。 – baskint 2010-06-22 02:54:11

不是一个真正的回答你的问题，但你仍然可以使用存储过程的实体框架：see here，基本上存储过程地图的方法调用你的上下文对象。

我的个人体验实际上与您的相反：我通常试图远离EF，因为它具有与您的应用程序紧密结合的趋势。关于sprocs的好处是它们允许一定程度的分离（例如，我可以在不修改客户端代码的情况下更新数据库）。但这当然只是我个人的看法。

来源

2010-06-22 05:24:18

是的，他们确实允许解耦，但这些sproc中的业务逻辑的数量是真的关注。它们也不是简单的CRUD操作，而是通过几个WHERE过滤器将十多个或更多表上的许多LEFT OUTER JOIN类型操作复杂化。然而我也看到你的观点，我会开始你的联系。谢谢。 – baskint 2010-06-22 16:27:46

这取决于你所工作的商店。我在许多商店工作过，这些商店对是否利用sprocs或应用程序层的代码存在强烈的意见冲突。问题是：你是否拥有更多熟悉维护plsql/tsql的人？

我个人很讨厌存储过程，并赞成ORM工具等，现在天，我宁愿保持应用程序代码的清洁。这只是在数据库中变得非常舒适之后。让数据库代码存在于它的本地环境中，并提供所有可用的工具。

来源

2010-06-22 02:50:11 Jubal

好点。数据库必须从早期的Access数据库发展而来，我想从90年代后期开始，我不确定。它使用'Y'或'N'字符来存储布尔（ugh！）过度标准化。我听说专家DBA和开发人员说每个sproc不会再有30个连接。我的下巴正在下降。我正试图让队友们有更多的感触，但我想用一些实际的经验。因此，这个问题。 ;） – baskint 2010-06-22 02:59:01

听起来像是将这些东西带入实体框架人员的主要工作。 :-)本身并不容易出错。尽管我感到你的痛苦！祝你好运先生！ – Jubal 2010-06-22 03:24:08

Why use Stored Procedures?

在实践中，你会最终重构从EF远在短短几年内，而您的存储特效仍然可以坐在那里准备在最新最好的客户层使用。客户端无关，封装等

来源

2010-06-22 05:15:36 gbn

这是一个有效的观点，但业务逻辑封装的数量，未经测试的业务逻辑实际上不能很好地对业务规则/逻辑进行“单元测试”。我宁愿让他们用C＃编写，并通过一些数据库集成测试来执行他们的执行。但这是我的看法。同意，sproc的确经受了时间的考验，但随着云计算即将到来，也许是时候离开了。 – baskint 2010-06-22 16:24:51

我没有提到业务逻辑应该打包到proc中，但他们将擅长事务处理，数据完整性，避免多次调用等。 – gbn 2010-06-22 16:26:47

针对存储过程的情况？

回答

相关问题