Question

我将用PHP编写我的Web项目框架。请不要告诉我考虑使用一些现有的框架（Cake，CodeIgniter，Symfony等） - 我已经看过它们并决定自己编写一个。

框架本身主要由模块系统，数据库处理程序和模板解析器组成。（当然还有很多其他的事情）

对于模块系统，我的意思是每个模块只有一个PHP文件和一个或多个与之关联的模板。一个示例模块modules/login.php使用templates/login.tpl进行设计。

现在每个人（？）都在谈论MVC（模型视图控制器）概念，大多数现有框架也使用它。

所以我的问题如下：

MVC对个人框架真的有效吗？
使用模块系统是不是一个坏主意？
你有没有为自己写一个框架？你有什么经历？

Answer 1

MVC对个人框架真的有效吗？

是的，它可以。虽然，它可能有点矫枉过正（如果你想学习，这不一定是坏事）

使用模块系统是不是一个坏主意？

这绝不是一个坏主意。

你有没有为自己写一个框架？你有什么经历？

当我是实习生时，我为我的小组的PHP应用程序编写了一个通用的安全框架。我学到了很多，但整个项目可能从预先构建的解决方案中获益更多。

当然，如果我刚刚安装了预先构建的解决方案，我就不会学到太多东西。所以你总是要考虑到这一点，特别是对于个人项目。有时重新发明轮子是你学习的唯一方法。

Answer 2

MVC对个人框架真的有效吗？

由于其模糊的解释，MVC意味着什么是业务逻辑，演示和输入处理。因此，除非您的目标是设计一个不涉及其中任何三个的应用程序，否则MVC在其模糊的意义上非常适合。

然而，它通常比你想要的更正式，因为它要求将想法物理地分离到不同的代码文件中。如果避免手续，可以更快速地设置快速和肮脏的任务或快速原型设计。

从长远来看，MVC所要求的是以维护，修改或添加的方式有益于应用程序的可持续性。你不会想错过这个。但并非所有框架都鼓励正确的做法。你发现你尝试过的各种实现都不足为奇。我个人最喜欢的是Agavi。对于我和其他人来说，在一个感觉不对的PHP框架世界中，Agavi出现了做正确的事情。阿加维值得一试。

使用模块系统是不是一个坏主意？

MVC要求您分离业务逻辑，表示和输入处理的组件，但它不建议如何布局文件。我认为这是您使用模块系统解决的挑战。回答你的问题：模块与子目录的服务相同。如果项目很少，即使文件可以逻辑地分成它们，也可能更难以打扰子目录。当项目数量增长时，现在找到它们很麻烦，子目录成为更好的选择。

框架将强调功能，允许您将模块作为自己的可配置实体处理。没有模块也可以存在相同的功能，也许是在一个更繁琐的庄园中。尽管如此，不要将模块主要视为系统。系统非常模糊，你可以根据你认为合适的设置进行调整。

你有没有为自己写一个框架？你有什么经历？

是的我已经编写了几个框架，其中包含各种解决Web应用程序问题的方法。我写的每一个这样的框架都只是一个重要的学习曲线。在我制作的每个框架中，我发现越来越多的构建软件的问题。在没有创造任何有趣的东西后，我仍然获益，因为当被要求制作一个程序时，我可以完全这样做。

如果这是您想要的学习体验，我建议您继续。否则，给Agavi一个机会。如果这也失败了，请确保您对框架的功能有清晰详细的说明。强行制作软件，努力工作，什么都不做的最简单方法就是不要事先决定你的软件完全会做什么。每次我遇到代码时，我脑子里唯一想到的就是我会做正确的。发生了什么是一个不同的故事：哦，我需要建立一个路由系统，因为这似乎是合乎逻辑的;嗯，好的，现在我需要一个好的模板系统;好的，现在是数据库抽象的时候了;但是，哎呀，多少思考;我应该从软件XXY的同一系统中寻找灵感。其中有一个共同的呐喊，首先要求使用现有的软件。

我认为我能做得对的原因并不是因为框架的所有细节都是错误的。事实上，我对他们的对与错一无所知，因为我从未与他们合作过。我做的工作是珐琅，感觉很不稳定。派生自己框架的最快方法就是从另一个框架中窃取螺母和螺栓并设计自己的珐琅。这就是您在构建应用程序时所看到的，坦率地说，这是唯一重要的部分。其他一切都浪费你的样板时间。但是，要学习如何构建软件，不要浪费时间。

如果您有任何其他问题，请询问。我很乐意以自己的经验回答。

Answer 3

我实际上也在和我的一个朋友一起编写一个php框架。我完全可以理解你的所作所为。

我知道你在做什么是靠近mvc。您将模板视为视图。而模块作为控制器。所以我认为没关系。你唯一需要的是模型。这将是某种积极的记录。

在我的框架中有类似的概念，除了我们现在正在编写自己的活动记录引擎。我觉得你做的不错。但是如果不看代码就很难说。

我发现只有一个问题需要解决。框架应该完美地整合在一起。在编写应用程序时，总是很难使模块看起来很好，而不必总是考虑模块。

Answer 4

MVC对个人框架真的有效吗？
使用模块系统是不是一个坏主意？

是的。但MVC是一种如此松散的设计模式，您可以在任何地方绘制模型，视图和控制器之间的界限。对我来说，最重要的部分是模型和视图。我只是有页面，php模块，通过从数据库填写模板生成HTML。页面是视图，数据库是模型。任何常见的特定于应用程序的代码都可以分解为“控制器”。一个示例可能是多个页面必须用于呈现数据的常见复杂查询。

除此之外，我还有安全数据库访问，简单模板和其他东西的实用工具。

你有没有为自己写一个框架？你有什么经历？

是。我很高兴我做到了。我可以保持简单。我非常了解它是如何运作的。除了我自己，我不依赖任何人。我可以保持简单但有用。

一些指针（0x912abe25 ......）：

每次抽象都需要付出代价。

不要开玩笑。你可能会后悔没有保持简单。添加恰当的抽象量。您可能会发现过度抽象，应该简单的事情变得过于复杂。我知道我犯了这个错误。记住你 - 不需要它。

适当范围您的变量

请勿执行

加载页面

      include_once('...page file ...');

预计页面文件将有一堆内联php来执行查找不同的全局变量。你失去了所有的范围感。如果从函数内部加载页面文件，这可能会变得很糟糕：

      function processCredentials()
      { 
           if (credentialsFail)
           {
                 include_once('loginpage.php');
           }
      }

此外，当涉及范围界定时，将插入模板的任何内容视为具有范围的变量。如果从与该模板关联的页面文件之外的某些内容填充模板（如主索引.php或其他内容），请务必小心。当你这样做时，不清楚究竟是什么填写了你以及你需要插入模板。

不要使用OO对数据库进行过度建模。

要简单访问数据库，请创建有用的抽象。这可能就像通过主索引将行提取到对象中一样简单。

对于更复杂的查询，请不要回避SQL。使用简单的抽象来保证您的输入的清理和验证。抽象数据库不要太疯狂。 KISS。

Answer 5

我想说MVC对我来说更有意义，因为感觉更好，但唯一的实际区别是你的login.php将同时包含模型（数据结构定义）和控制器（页面操作的代码）。您可以向模块添加一个文件，例如class.login.php并使用__autoload()来实现MVC结构。

Answer 6

我重构了一个大型PHP项目，使其更符合MVC。

我发现创建DAO层以集中所有数据库访问特别有用。我创建了一个daoFactory函数，它创建了DAO并将数据库句柄注入其中（同样是logger，我使用log4php，已经注入）。

对于DAO，我使用了很多数据库（mysql）的功能，比如存储过程和触发器。我完全赞同Doug T.关于避免过度抽象，特别是对于数据库访问：如果你正确地使用数据库（准备好的语句等），你不需要任何ORM，你的代码会快得多。但是当然你需要学习mysql（或postgress）并且你变得依赖它（特别是如果你使用了很多存储过程，就像我倾向于那样）。

我目前正在进一步重构，使用Slim php框架并转向restfull api：在这种情况下，不再有视图，因为所有内容都以json的形式输出。但我仍然使用smarty，因为它的缓存效果很好而且我知道它。

Answer 7

编写框架可能是一种有益的体验。需要考虑的重要一点是，您不要为了自己的利益而编写框架。编写框架的原因是为了简化开发。

由于它是一个个人框架，你应该考虑如何帮助你以更少的麻烦来发展。

我认为模板系统不是个好主意。想一想 - 使用模板系统的主要好处是什么？答案是，它可以帮助具有不同技能的团队共同开发应用程序。换句话说，团队的一些成员可以在用户界面上工作，他们不需要是PHP编码器。现在，个人框架最有可能被一个人使用，模板系统的好处变得无关紧要。

总而言之，您应该查看自己的编码习惯和方法，并发现将大部分时间花在典型项目上的任务。然后你应该问问自己如何自动完成这些任务，以减少时间和精力。通过实现这些自动化机制，您将不得不遵循某种约定（类似于API）。辅助机制和约定的总和将是您的个人框架。

祝你好运。

Answer 8

MVC不起作用
你不想被限制在你的“模块”的结构中;另外，让模板靠近代码（templates目录是个坏主意）
没有

re 1。：参见Allen Holub的Holub on Patterns。简要说明：MVC基本上要求你放弃面向对象的原则。

Tell Do Not Ask是一个吸引人的名字，可以帮助你保持一起作用于它的数据和代码。 Views 导致模型降级为getter和setter堆，如果有任何有意义的操作定义，则很少。然后，实际在控制器和视图（！）之间传播自然属于模型的代码，从而产生不健康的远程动作和紧密耦合。

模型对象应该显示自己，可能使用某种形式的依赖注入：

interface Display
{
    function display($t, array $args);
}

class SomePartOfModel
...
{
    function output(Display $d)
    {
        $d->display('specific.tpl', array(
            'foo' => $this->whatever,
            ...
        ));
    }
}

OTOH，实际上我发现大多数Web应用程序都需要一种不同的架构模式，其中 Model 被 Services 替换。一个活动的数据库，规范化的模式和特定于应用程序的视图有很长的路要走：你保持一起作用于它的数据和代码，声明性质使它比你在PHP中做的要短得多。

好的，所以SQL是一种非常冗长的语言。什么阻止你从一些简洁的DSL生成它？请注意，我不一定建议使用ORM。事实上，恰恰相反。如果没有 Model ，那么ORM几乎没有用处。您可能希望使用某些东西来构建查询，尽管这些应该非常简单，也许是为了避免使用这样的工具......

首先，让数据库公开的接口尽可能地适用于应用程序。例如，隐藏视图后面的复杂查询。在需要时公开特定于更新的接口。

大多数Web应用程序不仅是各自底层数据库的所有者，而且是他们唯一的消费者。尽管如此，大多数Web应用程序通过笨拙的接口访问他们的数据：标准化模式，简单模式或非规范化模式，结果使得一个操作更容易以其他地方的严重不适为代价（各种csv样式列等）。这有点令人伤心，而且不必要。

re 2：拥有统一的结构肯定是好的。你不想做的就是将自己锁定在模块不能使用多个文件的情况下。

模板应该与使用它们的代码保持接近，原因与组合在一起的代码应该保持在一起。模板是一种代码形式，MVC中的 V 。你需要细粒度的模板来允许（重新）使用。没有理由表示层不应该像代码的其他部分那样干燥。

PHP：个人框架

8 个答案:

每次抽象都需要付出代价。

适当范围您的变量

不要使用OO对数据库进行过度建模。