Question

我正在寻找关于在我的基于PHP的Web应用程序中重构数据访问层（DAL）的最佳方法的输入。我遵循MVC模式：PHP / HTML / CSS /等。前端的视图，中间的PHP控制器/服务，以及位于模型中关系数据库顶部的PHP DAL。很标准的东西。事情很好，但我的DAL变得越来越大（代码？）并且变得有点笨拙。

我的DAL几乎包含了与我的数据库交互的所有逻辑，并且包含如下所示的函数：

function getUser($user_id) {
   $statement = "select id, name from users where user_id=:user_id";
   PDO builds statement and fetchs results as an array
   return $array_of_results_generated_by_PDO_fetch_method;
}

注意：

我的控制器中的逻辑仅使用DAL
我没有使用框架（我是认为PHP是模板化的语言，没有必要通过框架注入复杂性）
我通常使用PHP作为程序语言，往往回避它的OOP方法（我喜欢OOP 发展，但宁愿保持这一点 PHP的复杂性）

当您的DAL达到这一点时，您采取了哪些方法？我有基本的设计问题吗？我只需要将DAL切成许多较小的文件（从逻辑上划分它）吗？感谢。

Answer 1

就你的架构而言，你的数据库中的每个表应该（通常）有自己的模型（PHP类），如果你不这样做，那么我会说你有代码味道。

如果您将每个表都作为模型，那么我不会担心每个类中的代码量。拥有“胖模特”和“瘦调控制器”是件好事。

如果你想要简化一些代码，你可以使用一个轻量级的数据对象包装器，就像PEAR的DB_DataObject一样。 DB_DataObject模型的几个示例：


$user = new User;
$user->get($user_id);


$user = new User;
$user->name = 'foo';
$user->find();
while($user->fetch()) {
...
}

使用像DB_DataObject这样的东西的好处是你抽象了很多低级别的PDO，你的类实现将更多地关注你的业务逻辑。

Answer 2

可能会从实际提出的问题中略微偏离一下，但是你可能会对Toon Koppelaars的一系列演讲感兴趣，他们是一位非常称职的Oracle DB小组，关于软件架构，已知（或者我应该说，未知）作为“The赫尔辛基宣言“。

请参阅http://thehelsinkideclaration.blogspot.com/2009/03/helsinki-declaration-observation-1.html

它可能会有点横向，但无论如何都很重要，关于你的问题真正的主题。

数据访问层，最佳实践

2 个答案: