我是OOP编程的新手。 但我认为我理解什么是ORM:在实践中,ORM库允许在对象中抽象数据库并处理它,就好像它是OOP编程中的类一样。
我对么? Eloquent是管理Laravel中ORM的库,并且使用它来扩展模型(MVC架构中软件的业务逻辑)
对,那是正确的
谢谢:在这个网络中存在一个类似这样的问题吗?(Newbye)
嗯,我不 程序员StackExchange可能会更好。 至少问题是关于ORM是什么的部分。 然而,关于ORM是什么,已经有很多问题和其他资源。 例如这个
tl; dr:ORM管理数据库中简单的基于整数的关系到您可以在代码中使用的类的实例的转换。
你在几个不同的领域感到困惑。
首先,很快,MVC是一个应用程序的一层;特别是它是表示层的一部分。您的业??务逻辑应完全独立于MVC层。
像MySQL和PostgreSQL这样的RDBMS本质上不利于建立和维护面向对象编程的各种关系。在经典博客示例中,Post属于User,用户可能有多个帖子。如果我们试图递归地序列化这些对象并存储它们,我们最终会得到很多循环(因而无限)的循环。
相反,我们使用索引和键系统在数据库中创建关于其他相关对象的永久注释。这些可能引用一个表,但不代表将以编程方式建立的具体关系。
那么我们就有了ORM。 ORM通过Eloquent中的外键和关系方法知道posts表中一行上的user_id列实际上与User对象相关。一旦你添加关系(见下文)就会发生这种情况,这样你就可以随时引用这个用户,只要用户存在,无需使用数据库,甚至不知道底层数据不是已经是一个对象。
我们可能会在Post.php中看到以下内容:
public function user() {
return $this->belongsTo(User::class);
}
如果我们有一个user_id为5,Eloquent使用一点语法魔法(特别是低级蛇案例类并附加_id)来找到id为5的用户。当你通过急切加载或延迟加载来检索它时,然后,eloquent将使用检索到的数据来水合User对象。
抽象在于,从技术上讲,类/对象不了解数据库结构,而Eloquent则处理与属性名称和列名称之间的转换。
MVC更恰当地是具有一些光耦合的三层:模型层(其中OP状态通常是业务逻辑所在的位置),控制器层和视图层。 只有MVC中的V是"表示层"。 Web框架可能会稍微复杂一些,因为客户端和服务器端都可能有多个控制器和视图,但无论哪种方式将MVC视为一个层都是不正确的。
在这里查看laravel.com上的文档
有时这是一个很好的做法,知道你是否与其他人或专业人士学到了什么。 没有任何人有可能成为teAcher