本机查询和存储过程与 ORM
随着 LINQ to SQL 和实体框架等 ORM 的普及，我对使用本机查询和存储过程产生了疑问。
我自然而然地倾向于 SQL 以及与 RDBMS 的直接接触。我喜欢对所发生的事情进行纯粹的控制，并且我喜欢我的跟踪准确地显示我在代码中调用的内容（存储过程等）。
但是我错过了 ORM 的哪些好处呢？仅仅是快速的发展过程吗？缺乏管理数据库和所包含对象的必要性？
如果不使用 EF 和 LINQ to SQL，我会错过什么？
As the popularity of ORMs like LINQ to SQL and Entity Framework increases, it makes me question using native queries and stored procedures.
I am naturally geared towards SQL and the direct contact with the RDBMS. I enjoy the pure control over what happens, and I like my traces showing exactly what I'm calling in code (stored procedures, etc.).
But what are the gains of ORMs that I am missing out on? Is it just the rapid development process? The lack of necessity to administer the database and objects included?
What am I missing out on by not using EF and LINQ to SQL?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为这里最大的影响是生产力；使用 EF（或任何其他 ORM）构建简单的 CRUD 接口非常简单。但当你不完全理解正在发生的事情时，问题就会出现。
例如，假设一个大对象，有几个子集合； ORM 有一个限制，即无法理解数据的集成方式，并且必须返回非规范化的数据以具体化该对象。这可能会对数据传输产生巨大影响。
另一件事是关于性能。也许您得到的用户界面应该执行许多计算，或者更新一个大对象及其依赖项。在这种情况下，我建议使用本机访问（存储过程等）来释放 RDBMS 的全部潜力。
总结：简单的接口、ORM；中型到复杂的接口、存储过程。
I think biggest impact here is productivity; it's real simple to use EF (or any other ORM) to build simple CRUD interfaces. But problems comes when you do not fully understand that's going on.
For example, lets suppose a big object, with several sub collections; ORMs have a limit do understand how that data is integrated and must return data denormalized to materialize that object. And that can be a huge impact on data transfer.
Another thing is about performance. Maybe you get an user interface which should do many calculations, or to update a big object and its dependencies. In this case, I suggest to use native access (stored procedures, etc) to unleash your RDBMS full potential.
Summary: simple interfaces, ORM; medium to complex interfaces, stored procedures.