03.05 实体
在实际应用中个,我们通常可以将一个实体理解为数据库中某个表格中记录的PHP中的类实现。
我们可以简单地说:有一个表格,保存了诸如用户名,密码,主页等用户信息,那么通过某种方式将这个表格映射到一个User
实体,这个实体有着诸如username
, password
, 这样的属性,也有类似setusername
这样的方法来设置某个属性。
或者,更SF的想法是,我有一个User
实体,其中定义了诸如username
,,homepage
这样的属性和一些方法来操作属性,我们可以要求SF和Doctrine根据我们这个实体的结构来创建相应的数据库表格以存续(persist)这样的用户信息。
以往我们总是先定义一个数据库结构,定义各个表格以及之间的关系,然后才是通过ORM将数据库结构映射回一个类。而现在,SF的推荐方式是先不要管底层数据库会怎样,我们先要关心的是我们的应用需要哪些实体的支持,这些实体怎样互相操作,又各自提供怎样的一些属性和方法。这些工作做完之后,才是数据库结构的映射和将来对象得以存续。
现有数据库再有对象是传统的思路;而先有对象再有数据库是SF提倡的思路。
在本书所讲述的应用开发过程中,我们会用到这两种不同的方式。
在开发过程中,我们会采用SF提倡的方法,对我们的实体进行一些微调,这些微调可能是会影响到数据库表格结构的。我们将会发现,这个反向(或者更应该说是正向?)的操作室无损的,不会影响数据库中现有数据。
也许,在我们的开发中,这样两个方向的调整还是需要进行若干次的。这样的循环没有一个固定的模式,我们要根据实际的需要和自己的经验来确定此时此地用哪个方向的映射最合适。
讲述了这么多实体的理论,我们来看一个典型的实体的代码。这是一个书籍表格的映射,文件位于:src/AppBundle/Entity/Book.php
:
对于实体的更多讨论,我们在后续章节会结合编程的过程加以进一步的介绍。