# 實體 在SF的術語中，實體（Entity）是一個對象，有自己的屬性和方法。我們都知道，根據面向對象的編程理念，一個所謂的對象是一個封裝的實體。這么來回說似乎有點循環定義的味道。但是，確實我們只能這樣來理解。 在實際應用中個，我們通常可以將一個實體理解為數據庫中某個表格中記錄的PHP中的類實現。 我們可以簡單地說：有一個`user`表格，保存了諸如用戶名，密碼，主頁等用戶信息，那么通過某種方式將這個表格映射到一個`User`實體，這個實體有著諸如`username`,?`password`,?`hompage`這樣的屬性，也有類似`setusername`這樣的方法來設置某個屬性。 或者，更SF的想法是，我有一個`User`實體，其中定義了諸如`username`,`password`,`homepage`這樣的屬性和一些方法來操作屬性，我們可以要求SF和Doctrine根據我們這個實體的結構來創建相應的數據庫表格以存續（persist）這樣的用戶信息。 這是一個很巨大的變動。對我們如何編程，先定義什么后定義什么的順序以及這個順序內涵的意義有著不尋常的影響。 以往我們總是先定義一個數據庫結構，定義各個表格以及之間的關系，然后才是通過ORM將數據庫結構映射回一個類。而現在，SF的推薦方式是先不要管底層數據庫會怎樣，我們先要關心的是我們的應用需要哪些實體的支持，這些實體怎樣互相操作，又各自提供怎樣的一些屬性和方法。這些工作做完之后，才是數據庫結構的映射和將來對象得以存續。 現有數據庫再有對象是傳統的思路；而先有對象再有數據庫是SF提倡的思路。 在本書所講述的應用開發過程中，我們會用到這兩種不同的方式。 在最開始的時候，我們用傳統的方法：先定義數據庫然后導出，并映射到一個個實體。這是因為我們的應用定義很明確，要處理的對象也非常明確。 在開發過程中，我們會采用SF提倡的方法，對我們的實體進行一些微調，這些微調可能是會影響到數據庫表格結構的。我們將會發現，這個反向（或者更應該說是正向？）的操作室無損的，不會影響數據庫中現有數據。 也許，在我們的開發中，這樣兩個方向的調整還是需要進行若干次的。這樣的循環沒有一個固定的模式，我們要根據實際的需要和自己的經驗來確定此時此地用哪個方向的映射最合適。 講述了這么多實體的理論，我們來看一個典型的實體的代碼。這是一個書籍表格的映射，文件位于：`src/AppBundle/Entity/Book.php`： ~~~ <?php namespace tr\rsywxBundle\Entity; use Doctrine\ORM\Mapping as ORM; /** * BookBook */ class BookBook { /** * @var integer */ private $id; /** * @var string */ private $bookid; ... ... /** * Get id * * @return integer */ public function getId() { return $this->id; } /** * Set bookid * * @param string $bookid * @return BookBook */ public function setBookid($bookid) { $this->bookid = $bookid; return $this; } /** * Get bookid * * @return string */ public function getBookid() { return $this->bookid; } ... ... } ~~~ 以上列出的只是該實體很小的一部分。一般而言，一個實體中將包含所有屬性（全部是`private`成員）和針對該屬性的R/W操作（對于某些只讀或者只寫參數，R/W操作會只有一個，但無論如何，都是`public`函數）。 對于實體的更多討論，我們在后續章節會結合編程的過程加以進一步的介紹。