MVC：在视图中应该有多少代码？ [英] MVC: how much code should be in a view?
问题描述
我是一个网络开发人员，我是一个编码器很长一段时间。但我从来没有使用过纯粹的MVC架构。现在我开始自己的项目，决定自己做html-css和雇用一个编码器。我们选择了流行的PHP-MVC框架。
I'm a web-developer and I was a coder for a long time. But I have never used a pure MVC architecture. Now I started own project and decided to make html-css by myself and hire a coder. We chose the popular PHP-MVC-framework.
第一步完成，一些页面被编码。在查看结果后，我有问题...在模板（视图）中应该有多少代码？
First steps are done, some pages are coded. And after looking to the result I've got the question... how much code is there should be in templates (View)?
例如，这里是一个模板file：
For example, here is a template file:
<?php $this->load->view('header'); ?>
<?php $this->load->view('banner'); ?>
<div id="items">
<?php
for($i=0; $i<count($main); $i++) {
echo '<div class="item">
<div class="name">'.$main[$i]['name'].'</div>';
if($main[$i]['icq']=='') { }
else { echo '<div class="phone">'.$main[$i]['phone'].'</div>'; }
echo '</div>';
}
?>
</div>
<?php $this->load->view('footer'); ?>
您认为此模板中有太多代码或正常吗？
Do you think there is too much code in this template or it is normal?
推荐答案
第一个答案实际上是点，但用户删除它（可能是由于同行压力）。基本上，您不希望模板中有任何逻辑。在理想的世界里，你有一个标签为所有的模型数据，但由于我们在一个HTML世界中，没有，所以你要么使用XSLT或使用ViewHelpers。
The first answer was actually spot on, but the user deleted it (probably due to peer pressure). Basically, you do not want any logic in your template. In an ideal world, you had a tag for all the model data, but since we are in an HTML world, there isn't, so you either have to use XSLT or use ViewHelpers.
让我们专注于ViewHelper方法。
Let's focus on the ViewHelper approach.
这很难维护：
<div id="items">
<?php
for($i=0; $i<count($main); $i++) {
echo '<div class="item">
<div class="name">'.$main[$i]['name'].'</div>';
if($main[$i]['icq']=='') { }
else { echo '<div class="phone">'.$main[$i]['phone'].'</div>'; }
echo '</div>';
}
?>
</div>
如果用Smarty替换PHP，它不会更好。这很容易维护：
And it won't get any better if you replace the PHP with Smarty. This is easy to maintain:
<div id="items">
<?php echo itemlist($items, 'template.htm') ?>;
</div>
在现在删除的问题下面有一个评论者反对这个代码不容易保持非编码器，因为现在他们不知道itemlist是在哪里定义的和它做什么。但是这是完全的乱码。想想一下。
Below the now deleted question, there was a commentor objecting this "code isn't easy to maintain for non-coders because now they don't know where itemlist is defined and what it does." but that's complete gibberish. Think about it for a second.
一方面，他们声称非编码器会遇到一个简单的函数调用的问题，但另一方面，他们希望他们理解PHP代码混杂的混乱HTML。设计师不关心演示逻辑，而只关心实际演示。输出。
On the one hand, they claim non-coders will have issues with a simple function call but on the other hand they expect them to understand the mishmash of PHP code mixed with HTML. A designer does not care about the presentation logic, but just the actual presentation. The output.
单个函数调用清楚地说：这里是一个项目列表，比这里是 code>回声一个div，如果icq被赋予可能是别的东西。函数调用与标签一样好。它清楚地定义了输入和输出。如何实现该输出与开发人员无关。
A single function call clearly says: "here be an item list", which is much easier to grasp than "here is a for that echoes a div and maybe something else if icq is given". A function call is as good as a tag. It has clearly defined input and output. How it achieves that output is irrelevant to anyone but the developer.
您的ViewHelper封装了表示逻辑。它是一个可以在所有视图中重复使用的代码段。这是更可维护的比复制和粘贴所有的逻辑一遍又一遍在需要的时候。在上面的例子中，帮助器有两个参数：
Your ViewHelper encapsulates the presentation logic. It's a snippet you can reuse across all of your Views. That is much more maintainable than copy and pasting all that logic over and over again when needed. In the example above, there is two arguments to the helper:
- $ items是一个数组或其他可遍历类型， / li>
- 'template.htm'是用于呈现数据的模板的文件名
I将使第二个是可选的，因为我认为它总是相同的模板。但由于评论者抱怨非编码者不知道在哪里看，我觉得有必要表明告诉非编码器在哪里看起来是多么容易。
I'll make the second one optional, because I'd assume it's always the same template anyway. But since the commentor complained the non-coder wouldn't know where to look, I felt it necessary to show how easy it is to tell the non-coder where to look.
function itemlist($items, $template = './templates/itemlist.htm') {
ob_start();
foreach($items as $item) {
include $template;
}
return ob_get_flush();
}
可能有更有效的方法来解决模板的包含。主要思想应该是清楚的。从实际模板隐藏表示逻辑。您的template.htm将如下所示：
There might be more efficient approaches to solve the inclusion of the template. The main idea should be clear though. Hide the presentation logic from the actual template. Your "template.htm" would then look like this:
<div class="item">
<div class="name"><?php echo $item['name'] ?></div>
<?php echo contact($item, 'icq' 'phone'); ?>
</div>
没有和缺失。无字符串连接或大括号。决定如何联系用户的逻辑也隐藏在ViewHelper中。所有的非编码器必须知道现在是ViewHelpers的参数，这很容易知道写入标签的属性。
No if and elses. No string concatenations or curly braces. The logic to decide how to the user can be contacted is hidden in a ViewHelper as well. All the non-coder has to know now is the arguments to the ViewHelpers and that's as easy as knowing which attribute to write to a tag. Give them a cheat sheet if necessary.
相关信息：
- http://martinfowler.com/eaaCatalog/templateView.html
EDIT
扩展这个答案。以上不是抽象的抽象的缘故。它是为了可重用性和可维护性。
Due to the two comments below I decided to expand on this answer. The above is not abstraction for abstraction's sake. It is for reusability and maintainability. I've already pointed that out above but let me explain that here again.
实际上，我觉得使用ViewHelpers是很奇怪的，因为你会有演示在两个地方，但不抱怨分离标题，横幅和页脚。这是同一件事。你隔离可重用的部分，并将它们放在自己的模板中。在该步骤中将逻辑与模板分开只是自然的下一步，以实现更强的可维护性。
Actually, I find it odd to object to using ViewHelpers because you'll have "have presentation in two places" but not complain about separating header, banner and footer. It's the same thing. You isolate parts that are reusable and put them into their own templates. Separating the logic from the template in that step is just the natural next step to achive even more maintainability.
包含逻辑的视图模板实际上是一个脚本而不是一个模板。任何包含组合自身逻辑的视图模板都注定要重复自己。这可能不是小网站的问题，但如果你正在一个网站有十几个甚至数百个视图和小部件，不抽象这些部分将导致代码重复。将所有的逻辑放入模板，它很快就会成为一个混乱的混乱的条件的c& p'ed标记。对于任何重复，你将加倍改变它需要的时间。添加内联样式和突兀的JavaScript，并且正在维护地狱。
A view template that contains logic is effectively a script and not a template. Any view template that contains the logic to assemble itself is doomed to repeat itself. This might not be an issue with small sites but if you are working on a site with a couple dozen or even hundreds of view and widgets, not abstracting these parts will lead to code duplication. Put all the logic into the template and it will quickly become a tangled mess of c&p'ed markup mixed with conditionals. For any duplication, you'll double the time it takes to change it. Add inline styles and obtrusive Javascript and you are in maintenance hell.¹
如果您在应用程序的其他部分使用OOP，那么为什么要在您的视图？如果你理解你应该从你的HTML中分离Javascript和CSS，为什么你会把PHP混合到你的模板中？这没有意义。 OP的代码片段是一个脚本，而不是一个模板。因此，它是开发者的领域。因为你应用所有的好的做法，你也适用于你的应用程序的其他部分。这包括将逻辑分离为函数和/或类。
If you use OOP for the other parts of your application, then why would you go procedural in your view? If you understood that you should separate Javascript and CSS from your HTML, why would you mix PHP into your template? It doesn't make sense. The OP's code snippet is a script and not a template. As such, it is the domain of the developer. And because of that you apply all the good practise you apply to other parts of your application as well. And that includes isolating logic into functions and/or classes.
授予一个设计师查找脚本可能不会立即知道发生了什么。但是再次，她可能不知道，一旦你开始添加本机PHP函数。什么是 mb_strimwidth 做？和 substr ？什么是？：构造？您添加的实际PHP越多，对非开发人员的阅读越难。
Granted, a designer looking into a script might not immediately know what's going on. But then again, she might not know that either once you start to add in native PHP functions. What's mb_strimwidth doing? And substr? What's that ?: construct? The more actual PHP you add, the harder it will be to read for non-developers.
如果你想让设计师在模板上工作，不要给他们脚本。给他们模板。如果你这样做，隔离逻辑从它和替换它容易抓住函数调用。使用清楚地传达函数功能的函数名称。所以设计师只需要知道我使用这个输入，我总是得到那个输出，我不在乎输出是什么，我会留给开发人员。
If you want to have designers work on templates, don't give them scripts. Give them templates. And if you do, isolate the logic from it and replace it with easy to grasp function calls. Use function names that clearly communicate what the function does. So the designer only needs to know if "I use this with that input, I will always get that output. I don't care how that output comes to be. I'll leave that to the developer".
将逻辑分离为函数（或类）还可以直接测试用于在该页面上独立渲染特定部分的逻辑。您不必设置创建页面所需的整个环境，而只需传递所需的输入并断言它的输出（这就是为什么函数缓冲字符串而不是输出它的btw）。
Isolating the logic into functions (or classes) also gives you the immediate advantage of being able to test the logic used to render specific parts on that page in isolation. You don't have to setup the entire environment required to create a page, but just pass in the required input and assert it's output (that's why the function buffers the string instead of outputting it btw).
¹对于那些认为这不是问题的人，我强烈建议您找到一个真正保留视图模板中所有逻辑的旧应用程序。尝试改变几件事。一旦你吃了2500行意大利面条代码，每个至少有500个字符，并且包含重复的PHP，HTML，CSS和JavaScript的混合，你会知道我在说什么。
这篇关于MVC：在视图中应该有多少代码？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
