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