我的 Web 項目有一個名為 的類DB_CONNECTOR，其中捆綁了與 mysql 數據庫交互的所有函數。這些函數包括get_user()、add_user()、change_user_attribute()等等。在每個函數中都會執行 sql 查詢，并且作為良好實踐，我使用準備好的語句（帶有命名參數）。目前，與數據庫的連接是在類的構造函數中建立的，并且所有語句都在那里準備。我認為這是一個好主意，因此所有語句都立即準備好執行?，F在我意識到我的用例通常是創建一個 db_connector 對象，執行一個或兩個函數，然后對象生命周期結束，在稍后的步驟中可能會構造（或不構造）一個新的對象。因此，我不再那么確定將準備好的語句放入構造函數中是否明智，因為可以預見的是，我最終會得到至少 20 個或可能更多的準備好的語句。所以我的問題是：即使只使用一兩個語句，在構造函數中準備所有語句是否是一個好主意？或者我應該在執行之前在函數中準備它們，以避免不必要的準備工作給數據庫帶來壓力？
1 回答
森林海
TA貢獻2011條經驗 獲得超2個贊
這個答案是基于我的經驗和拙見，但我會盡力闡述我的論點，這樣它不僅僅是一些隨機的人的觀點。
我不認為數據庫連接一定是應用程序中的核心對象，更不用說是唯一的對象了。它期望為用戶看到一個完全不同的類，因此您稍后可以為其他所有內容提供進一步的類。否則，您的應用程序最終將由 5000 行文件中的單個類組成，并且您的類將不適合在實例級別跟蹤實體數據，并且您需要在方法調用中傳遞變量。這幾乎就是 OOP 服裝中的程序代碼。
另外，我不認為讓你的User類繼承Database（盡管如此）是很實際的。交錯數據庫連接和業務邏輯對象并沒有真正簡化應用程序設計，實際上使某些部分變得更加困難。
數據庫層本身的設計非常標準化：
每個應用程序一個連接（或更多...您可能需要連接到多個源?。?/p>
每個查詢一個語句。
這正是 PDO 的工作原理。
鑒于此，讓數據庫類成為實體的又一個依賴項而不是它們的祖父母項會更容易。這種依賴關系的注入可以通過不同的方式完成：
使其成為類屬性：
public function __construct(\PDO $connection)
{
? ? $this->connection = $connection;
}
將其傳遞給他們實際需要的方法（如果不是很多）：
public function getOrders(\PDO $connection)
{
? ? $stmt = $connection->prepare('SELECT ...');
}
...或者使用您可以在 Packagist 找到的那些奇特的依賴注入容器之一。
請注意，還有對象關系映射(ORM)、活動記錄模式……這些是完全不同的解決方案系列，可能適合您的需求，也可能不適合您的需求，具體取決于您的用例，但不是我在這里描述的內容。
話雖如此，很明顯，您在需要的地方準備了報表。這種設計甚至不允許其他情況;-)
- 1 回答
- 0 關注
- 127 瀏覽
添加回答
舉報
0/150
提交
取消