定制PHP框架反馈

我已经学习OOP编程大约一年半了，并且已经开发了一个我通常遵守的相当标准的框架。我希望得到一些反馈或意见，告诉我如何改进某些功能，或者是否有一些事情我忽略了

查看模式

1） 基本上，一切都从Index.php页面开始。我要做的第一件事是需要我的“packages.php”文件，它基本上是一个配置文件，用于导入我将要使用的所有类和函数列表

2） 我的index.php文件和我的类之间没有直接的通信，我所做的是用我的viewfunctions.php文件“整理”它们，它本质上只是类的一个管道，这样我就可以在html中编写

而不是

Plus，我可以运行几个小布尔函数，以及视图函数脚本中没有的，可以更好地定制类的输出

3） 通过数据库引入的任何信息都是从与数据库类直接通信的对应类开始的，该类是唯一允许与数据库直接通信的类（允许我使用自定义类代码运行所有查询）

输入模式

1） 任何用户输入都会发送到my userFunctions.php

2） 然后，我的安全类被实例化，我在其中发送任何已发布用于验证和验证的用户输入

3） 如果输入通过了我的安全检查，那么我将它传递给我的DB类，以便输入到我的数据库中

反馈

我想知道在总体结构中是否有明显的缺陷，或者我可以改进的方法

提前感谢您的投入。我知道对于这个问题没有真正的“正确”答案，但我想，为了获得一些关于构建框架的有力建议，需要进行几次投票

---

-我能看到的唯一问题（没有看到代码）是SQL将无处不在。我建议在DB连接类前面创建一个“模型”层。这样，所有sql都集中在一个位置（将其分解为多个模型，等等）。它使维护更加容易（如果您想向表中添加列、优化查询等）

---

否则，这看起来是一个好的开始

我建议您做的一件事是继续将函数划分为类。我理解你避免实例化的观点，但是考虑一下：任何框架都将需要积累大量的函数。 而不是做

您最好创建一个页面类，该类的所有函数都在静态调用的该类中。然后，您的代码变成

更具描述性的命名约定，在以后尝试避免命名冲突时将变得至关重要（您只需避免50个类的名称冲突，而不是2000个函数）

我将研究模型-视图-控制器设计方法（正如ircmaxell在他的帖子中暗示的那样）。许多功能强大、编写良好的框架都应用了这一原则，而不仅仅是PHP框架。我的建议-研究应用程序应该如何控制-非常灵活，创建者非常好地使用静态变量来控制类实例化

---

祝你的框架好运

介绍得不错。我肯定会深入了解其他流行的框架

---

乍一看，我建议您看看是否可以找到一种方法，只加载每个请求所需的类。如果类库变大，为每个请求加载它们可能变得不可行。

是否使用自动加载程序？看来你会用到很多要求。。。也许我只是误解了。我认为您正在编写自己的框架是非常棒的。我也不认为它是“重新发明轮子”，因为你写它是为了完成你想要完成的任务，并且可以控制你项目的总体重量，因为从大多数标准来看，你对OOP还比较陌生，我相信从经验中你学到了很多东西。创建自己的框架，尝试改进其他人的代码，学习其他人如何做事以及为什么做事是一种令人惊叹的学习体验，在我看来，这将极大地提高您的编程技能和理解能力

+1用于精彩的演示和关注点分离。实验很有趣，演示很好，但我不明白我们为什么要重新发明轮子。难道还没有足够的框架吗？@baloo我会告诉你我的绝对理由。因为我真的很喜欢。巴鲁：“不要重新发明轮子”之所以有效，是因为轮子被认为是完美的。有没有适合所有用途的框架？@baloo没有任何争论（我同意你的观点，并且会补充说，大多数框架缺乏测试会使问题加倍）。。。我就是受不了“不要重新发明轮子”这句话。。。它爬到我的脊背上，这是真的。我的userfunction.php和view类中有大量的查询代码。我使用一个类似于$dbConnect->runQuery（$query）的函数运行DB类的实际查询。。但实际的查询字符串写在视图类（或用户函数脚本）中。。。基本上，

$view=newview（'path/to/template'）然后将变量分配给视图
$view->title='blah'。。。然后，您需要做的就是
echo$view无需
$viewObject->get_title（）在模板内部，只需
echo$title…我对这件事感到困惑。我认为你说得很对，“模范”班是一个巨大的好处。但我也非常相信大卫·海涅迈尔·汉森（David Heinemeier Hansson）的哲学，即@Josh-我同意这种观点