php - 松散耦合的 MVC 的替代方案？

Question

我在一家网上商店工作，担任 PHP 程序员。大多数时候，我们使用良好的编码实践，但整个站点的结构不多。

我现在已经进入了对我们的一些实践感到厌倦的阶段，我想以一种有用的方式扩展、简化和生成一些东西，这不仅对我有用，而且对办公室里的混合程序员 Web 开发人员也有用。

一位员工给我们留下了一个用 PHP 编写的 MVC 站点，我不得不稍微维护一下它，我知道它是如何工作的，但有我的提示，我的主要提示是它与依赖于其他。我看到了关注点分离的优势，但这会让除了我看代码的任何人都感到困惑。

例如，如果我需要向站点添加新页面，我必须添加一个 View ，然后添加一个模型，然后更新 Controller 。制作新页面的临时方法比这简单得多，不需要程序员。

我的判断是，这是构建(而不是维护)网站的更好方法。

不过，如果我有一些设计模式可以有效地重用代码而不依赖于站点中的多个位置，那就太好了。

所以我的问题是，是否存在一种用于构建和维护松散耦合的网站的设计模式？我不是在寻找 MVC 的细微变化，我需要的是一些完全不同的东西，也许是某种类型的插件方法。

编辑:

感谢您到目前为止的回答!另一种说法是，我希望代码在我的办公室里做得更好。我是 A) 插入 MVC 还是 B) 找到/构建一个不会让半程序员感到困惑的替代方案。我们已经将类用于诸如数据库连接和表单帮助之类的事情。这道题的重点是探索B。

Answer 1

在代码因高度解构主义而令人困惑与代码因执行 X 所需的所有内容都随机分散在单个文件中而令人困惑之间总是存在折衷。

后者的问题在于，究竟什么是将事物拆分为单一模块的“直观”方式因人而异。高度分解和分解的代码几乎总是更难理解，但一旦你这样做了，维护就变得容易了。我不同意除了作者之外的任何人都会感到困惑。使用像 MVC 这样的大范围模式是因为随着时间的推移，更容易发现它们并处理围绕它们构建的项目。

使用 MVC 的另一个优点是，如果您不坚持分层，您通常不会使应用程序更难以为后来者维护。这是因为现在您有一个预定的位置来放置实现新功能的任何方面。

就紧密耦合而言，如果层与层之间没有某种联系，您就无法真正实现功能。松散耦合并不意味着这些层完全不了解彼此——它意味着一个层应该不知道其他层是如何实现的。例如: Controller 层不关心你是使用 SQL 数据库还是只是编写二进制文件来在数据访问层持久化数据，只是有一个数据访问层可以为它获取和存储模型对象。它也不关心你是在 View 层使用原始 PHP 还是 Smarty，只关心它应该以一些预先确定的名称为它提供一些对象。一直以来， View 层甚至不需要知道有一个 Controller 层 - 只需要它被调用并使用数据以显示在/something/提供的上述名称下准备就绪。