我一直在尋找如何設計我的php類來分離我的業務邏輯和我的數據層在線幫助。我開始設計一個我認爲很酷的課,但後來發現了PDO和ADODB,並有一個很好的facepalm時刻,意識到我正在重新創建輪子。我現在的問題是我仍然不太明白如何區分我的邏輯和我所有的SQL查詢。在這個例子中,我該如何分離我的SQL和業務邏輯?
我從我的數據庫模式中刪除了大部分內容,並放下這兩個表格,因爲我認爲它們會很容易理解。比方說,我有文件的路徑,他們被保存在我的服務器上的目錄(這些目錄可以在其他目錄中)。假設我需要基本功能,例如從我的一個文件中獲取根目錄或獲取當前目錄中的目錄列表。
+--------------------+ +----------------+
| Files | | Directories |
+--------------------+ +----------------+
| id | | id |
| name | | name |
| path | | directory_id |
| directory_id | +----------------+
+--------------------+
請問一個精心設計的類是這樣的:
class Files {
public function __construct($file_id) {}
public function getDirectory() {}
public function getRootDirectory() {}
public function getPath() {}
public function move($directory_id) {}
}
class Directories {
public function __construct($directory_id) {}
public function getRootDirectory() {}
public function move($directory_id) {}
public function listContent() {}
}
當我取回我的使用中通過構造函數傳遞的ID構造對象的所有數據?我是否應該在構造函數中傳遞一個PDO對象,還是缺少一些有價值的設計模式?所有的SQL都應該在這裏硬編碼嗎?我用PDO得到的一件事就是我可以很容易地從MySQL切換到MSSQL,但兩者在SQL的語法上有差異,所以不會導致我的問題?
我知道這些都是更理論性的問題,沒有一個好的答案,但我缺乏工作的同事來討論這個問題(我不是在開玩笑,當我說他們甚至不知道設計模式是什麼),所以我發現自己轉向到網絡。如果我的問題太模糊可以隨意建議一個很好的討論類型的地方,我可以問這種東西,我會非常感激:)
我不認爲有任何理由將mysql和app邏輯分開。這通常是邏輯演示 – dynamic 2011-06-02 20:40:09
所以我寫在那裏的類會很好? DMBS的變化意味着我必須去修改每個類中的SQL語句(因爲一些DBMS在它們的SQL語法上有差異)? – Gazillion 2011-06-02 20:44:01
ORM解決方案通過抽象接口來解決DBMS更改的問題。 – 2011-06-02 20:45:25