我一直在寻找如何设计我的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