0

现代 MVC 框架有自己的数据访问层实现，不需要编写 SQL 语句。在性能和可扩展性方面，是否有任何缺点，例如，在使用时

$user = User::where('email', '=', $email)->first();

而不是在原始 SQL 中使用准备好的语句

$user = DB::connection()->pdo->prepare("SELECT * from users where `email` = ? "  ) ;

由于 Laravel 和 Cakephp 等 MVC 框架也允许使用后一种方法，因此我不确定这两种方法中的哪一种在性能和可扩展性方面更好。

4

3 回答 3

3

Rant：
你所谓的“现代 MVC 框架”（除了少数例外）与实现 MVC 相去甚远。而那些“不需要 SQL 语句的层”实际上在大型项目（应该实际使用 MVC）中是极其有害的。

我的建议是避免使用任何内置的 ORM 或查询构建器。与所谓的“mvc 框架”捆绑在一起的 ORM 通常是活动记录的实现，其用例极为有限。基本上，仅当您仅使用基本的 CRUD 操作（没有JOINs 或其他高于初学者级别的 sql 查询）并且仅使用简单的属性验证（没有交叉检查的字段或与其他实体的交互）时，基于 AR 的域实体实现才是实用的。从技术上讲，您可以在更复杂的情况下使用活动记录实例，但随后您将开始产生技术债务。

最好的选择是将域逻辑与存储逻辑分开，并分别为模型层的每个方面实现域对象和数据映射器。

于 2013-02-26T11:28:13.423 回答
2

是的，在性能和可扩展性方面都存在缺陷。

所有这些 ORM 和 AR 仅在使用基本查询时都非常好。
但是当涉及到一些复杂的问题时，他们要么变得难以忍受的复杂，要么变得束手无策。
没有办法在这些时髦的运算符中注入“USE INDEX”、“DELAYED”或类似的性能提升命令。

可扩展性也是如此。
每次你要使用任何非标准的运算符时，你都会摸不着头脑。

还有一个便携性问题。
SQL 是网络开发者的通用语言，每个人都可以阅读和编写它。而专有的 ORM 可以修复它们。

然而，您的第二个代码同样丑陋且无法使用。

$user = DB::connection()->pdo->prepare("SELECT * from users where email=?");

DB::connection()->pdo->prepare()不返回任何用户。它返回一个语句句柄，必须在以下几行中使用该句柄来获取实际的用户信息。
在脚本中添加大量无用的代码。
这是从标量中选择的序数情况。尝试使用INSERT或仅使用IN()语句，您的代码将被炸到几个屏幕高。

为什么不让它真正获取用户信息呢？

$user = DB::conn()->getRow("SELECT * from users where email=?s",$email);

看——你保留了你的 SQL 却让它可用。

于 2013-03-01T12:25:24.840 回答
0

当然，您将始终有运行类和组装查询的开销。

然而，它可以帮助您防止错误。像“were id=”这样的错字不会发生（或不应该）。除了那些层已经为你做了很多事情。

像转义、解析、验证等......所以要承担开销，但要确保不会发生很多故障或安全问题

于 2013-02-26T07:13:14.507 回答