0

我一直喜欢动态代码。很容易添加很酷的新功能的代码，无需做太多工作。出于这个原因，我构建了许多动态框架并在我的项目中使用它们。有些很小，有些很大。

举个例子，我构建了一个小的自定义错误报告框架，我现在几乎所有的项目都在使用它。

这是它如何工作的一个简单示例：

error_reportLibrary.php - 这是所有魔法发生的地方。类和所有方法都在这里。这是需要框架时包含的文件。

error_reportConfig.php - 这是我的配置所在（错误类型等）。这是这个文件的一个例子，它可以很好地解释这个小框架是如何工作的：

（代码中的注释应该解释每个元素作为设置的作用）

# ------ Main Settings ---------

$error_handlingSettings['errorStat']=true;//set this to false, and I wont display any errors. I don't care what the other errorTypes have to say.
$error_handlingSettings['default_highlight_color']="red";//this is the default highlight color that will be used if no color is defined for a specific errorType

# ------ Open API -------
$error_handlingSettings['open_api']['status']=true;//set this to true and I'll show errors for the Open API
$error_handlingSettings['open_api']['highlight_color']="#0ff";//shall I highlight any errors that occur for this specific type? if so, set this to a color.
$error_handlingSettings['open_api']['onRemoteAddr']=true;//shall I display errors to specific IP addresses?
$error_handlingSettings['open_api']['remote_addr'][]="86.8.168.228";//so I will show to this IP
$error_handlingSettings['open_api']['remote_addr'][]="127.0.0.1";//and this IP

# ------ SQL Core -------
$error_handlingSettings['sql_core']['status']=true;//set this to true and I'll show errors for the SQL Core
$error_handlingSettings['sql_core']['highlight_color']="orange";//shall I highlight any errors that occur for this specific type? if so, set this to a color.
$error_handlingSettings['sql_core']['onRemoteAddr']=true;//shall I display errors to specific IP addresses?
$error_handlingSettings['sql_core']['remote_addr'][]="86.8.168.228";//so I will show to this IP
$error_handlingSettings['sql_core']['remote_addr'][]="127.0.0.1";//and this IP

所以你可能会说，每个错误类型只是我正在使用框架的项目的不同部分（例如，SQL Core 是我使用的数据库框架。所以如果发生任何数据库查询问题，这个 errorType 将是打印错误时查看）。

所以对于打印错误，这是语法：

errorModule::doError("errorType","error messege");

如您所见，我还可以做一些额外的小事。就像显示到某些 IP 地址并突出显示错误文本，我可以自信地说：不会影响框架的可扩展性。

请记住，以上只是我在项目中创建/使用的动态框架的一个示例。

现在，问题（几乎）：我的几所大学告诉我，像上面这样的动态框架在可扩展性方面很糟糕。尽管它们非常易于维护。因此，如果我在一个每天收到 100 万次以上请求的 Web 应用程序上使用上述框架，它会完全搞砸……

现在我并不反对他们的意见（实际上......）但我想知道这是为什么？为什么像上面这样的动态框架被认为不利于可扩展性？

4

2 回答 2

2

我认为您在创建“动态框架”时没有抓住重点。

我早期的许多 PHP 代码的功能都是这样的；一个有一堆方法的类，也许还有一个构造方法来设置状态，使用全局变量来跟踪数组中的配置。与完全面向对象的方法相比，这些都使用了大量内存；虽然是比“现成”解决方案更少的内存和更快的速度；与我现在设计框架的方式相比，没什么。

您似乎没有利用接口、抽象类、类和接口继承等东西。这些类型的框架确实可以扩展，因为原始代码库非常小并且利用了特定的 OOP 功能（如 PHP 5.x 的魔术方法）。

将一个您认为在服务器上运行速度足够快的脚本乘以 100，并且您遇到了问题；并且您的内存不足，打出页面；事情会爬到你被迫重新启动/在服务器上投入更多资源的地步。

为什么？写得很糟糕的程序代码试图表现 OOP，甚至试图看起来像它，只是将旧习惯包装在一个新包中。

于 2012-06-17T01:12:57.387 回答
0

一般来说，PHP 既慢又笨重。它是高级别的，这意味着每条线路都携带“行李”。单行 PHP 代码将转换为大量低级指令是很常见的。

您仍然可以扩展严重依赖 PHP 底层系统的“动态”框架，并且不会在高级抽象上浪费大量时间或内存。

在我看来，一旦在生产环境中大吃一惊，大型、“方便”的框架往往会导致比它们解决的问题更多的问题。我最喜欢的老师总是提醒我 KISS - Keep It Simple Stupid。

当然，如果您想要真正可扩展的性能，您可能希望使用hiphop编译您的 php，或者使用 C++ 或 D 等编译语言编写您的应用程序。

于 2012-06-17T01:36:20.963 回答