一个视图应该有多重的服务器逻辑？
我正在调试一个代码点火器应用程序，它在显示博客帖子列表时会间歇性崩溃(500错误)。
崩溃发生在页面重新加载的20-30%，并且似乎与服务器配置错误的内存问题有关。
First --我在发送到视图页面的每个数组下面执行print_r($array); exit;，从而降低了控制器。如果您只是输出数组(而不传递视图)，则没有问题--从来没有超时。
所以我不认为查询逻辑有问题。此外，CI的分析器显示页面正确加载时的查询次数<.001 (当它崩溃时，我得到500错误，无法读取分析器的信息)。
Next，我接着介绍了视图的print_r，该视图为控制器发送的数组设置了循环。这是一个瓶颈，偶尔会导致500个错误。
该应用程序的设计方式是单一视图处理控制器发送的所有数组，并生成具有最终输出的HTML页面。
正因为如此，视图具有很多PHP逻辑。在运行foreach循环之前，几个数组拆分来插入广告单元，对post参数进行条件测试，嵌套foreach循环等等。
它相当复杂，但可读性很强。但是，我不知道它是否有太多的逻辑，以及这个逻辑的负载是否应该被分割成更小的片段(多个视图)，然后合并成一个最终的HTML字符串。
景物
- 30-50
if / elseif，一些嵌套的 - 6-7
foreach，一些嵌套的 - 5
array_splice众多的empty和isset
你对这个问题有什么看法？您通常避免逻辑上的大视图吗？有什么建议吗？
请注意，我并不是为了网页设计师等而要求“清理”视图，就像在其他讨论中一样。这里我的重点是，如果这种结构可能导致超时，以及可能的解决方案是什么。
回答 3
Stack Overflow用户
发布于 2012-05-21 15:14:09
首先，这不是一个模板代码可读性的问题--复杂性和bug的存在之间有很强的相关性。圈复杂度是度量复杂性的一种方法；根据您发布的信息，该模板的圈复杂度至少为60。在我们所有的项目中，我的目标都是圈复杂度< 8，当我们到12岁时，我会感到恐慌。
如果您的视图代码包含错误--不只是一个超时的东西，而是通过逻辑树的一些奇怪的路线--您看这些代码就无法很好地描绘出来，我也不会感到惊讶。
Williams模板库为您提供了几个这样的工具--例如，您可以定义备用视图来处理"if问题，呈现像这样，如果post呈现像那样“的逻辑。您也可以在这里使用区域为您的利益。
有一种假设认为，由于视图处理的是用户界面，所以它们就不那么重要了--但这根本不是事实。
因此，让我们假设您将视图重构为一个更简单的结构。这会影响处理器负载吗？好吧-呃-取决于。
通常，“可维护性”和“性能”必须相互抵消。典型的例子是汇编程序代码与解释语言--对大多数人来说，汇编程序很难维护，而解释脚本语言则要容易得多；另一方面，毫无疑问哪种语言更快。
在您的例子中，我认为代码总量会增加--例如，作为重构的“提取方法”会增加几行代码，但是缓存应该更容易一些。还应该更容易识别错误发生的确切位置。
Stack Overflow用户
发布于 2012-05-21 14:31:55
你对这个问题有什么看法？
THere是您精确定位它的瓶颈。现在，如果视图性能为500 (超时)，则视图性能是不可接受的。如果要使它变得可用，就需要对其进行修复。
您通常避免逻辑重视图吗？
一直都是。这就是MVC模式设计的目的。尽可能多地保持控制器的逻辑，视图应该仅表示。
似乎太过分了，试图把它放在一个视图中。如果您想发布一些代码，就更容易对需要查看的内容提出建议。对我来说，最大的违法者是conditionals testing for post parameters。我认为这几乎肯定属于你的控制器。这些贴子是用来做什么的？
如果post参数指定输出类型，那么将其划分为不同的视图将更加清晰，而不是在一个超级视图中处理多个不同的输出类型。
Stack Overflow用户
发布于 2012-05-21 14:33:41
首先，我首先检查php设置中的执行时间限制。您所描述的情况非常类似于这个问题:有时脚本设法及时到达那里，有时却没有。)更多关于这里的信息。
第二，是的，你应该避免逻辑上的重见。老实说，我不知道如何在CodeIgniter中这样做，但是在Zend中有一些所谓的视图帮助程序，可以用来将视图相关(但很重)的逻辑从模板中分离出来。
最后，您是否已经使用XDebug或其他类似工具对您的脚本进行了描述？
UPDATE: --当“post参数的条件测试”舒适地坐在视图中(并且只是拒绝所有移动到控制器的尝试)的情况是……至少可以说是有趣的。对不起，那么使用MVC框架有什么意义呢？
https://stackoverflow.com/questions/10687182
复制相似问题
腾讯云开发者
