我的php架构可靠吗?

你的建筑并不完美。它永远不会完美。永远。完美是不可能的。这是应用程序开发、编程和整个世界的本质。会有一个要求来添加一个功能,或者改变你的业务逻辑,你会回到这个架构,说“我到底怎么认为这很糟糕。”(希望……否则你可能没有学到任何新东西!)

或者相反:

这个架构在我需要的地方发挥作用,并允许我 get stuff done

你可以改善这一点的一种方法是

这将有助于你 将业务逻辑与HTML分离 ,使其更易于维护。

这是设计应用程序的常见方法。

让另一个类处理动作委托 。不过,这实际上取决于应用程序的复杂性。

这本书 PHP Objects, Patterns and Practice

我要抛出的第二件事是,数据模型的复杂性很重要。如果这是一个基于现有或相当平坦的数据库模型的简单CRUD应用程序,那么您可能对这些数据库访问类没有问题。但是,一旦你的模型变得更加复杂,无论是层次结构还是多态性,它都会崩溃。你需要一个更强大的ORM。

你的“控制器/调度器”方法似乎很合理。switch语句避免了对任何类型URL的需要->代码映射,这很难管理,需要缓存来扩展。

那是我的0.02美元

从安全的角度来看,你的类和操作来自你的post变量,这可能是危险的,因为你应该 信任来自用户的任何信息。假设你的类/动作看起来像这样:

class1
{
  action1.1
  action1.2
  ...
  action1.N
}

class2
{
   action2.1
   action2.2
   ...
   action2.N
}

作为一名攻击者,我首先要考虑的是进入一个动作与其适当类别不匹配的状态。我会尝试使用action2.1而不是action1.1提交class1。

话虽如此,我的假设是,你已经得到了某种形式的验证,所以这不会发生。这让我想到了我最初的帖子:如果你的建筑适合你,那么它也适合你。看看你问的问题:安全性、灵活性、可扩展性,然后自己评估它们。找出自己的缺点。如果你不知道如何评估安全性/灵活性/对该主题的其他了解,请练习并应用它。

3. 安全性:你提出的架构的缺点是,你真的需要投资于安全测试。由于您的所有重定向/路由代码都在process.php中,因此该文件有很多责任,对它的任何更改都可能导致潜在的安全漏洞。这不一定是错的,你只需要意识到风险。

4. 可扩展性:您的架构是平衡的,看起来非常可扩展。由于您已按class:actions对其进行了细分,因此可以在任何层添加缓存以提高性能。添加额外的数据访问模型层也将帮助您在最接近数据库的层进行缓存。

最后,尝试每种架构,不要害怕犯错。看起来你已经对MVC有了很好的理解。提高架构能力的唯一方法是在“现实世界”中实现和测试它。