self-reference - 最佳实践 : Self-referential scripts on a web site

Question

根据更有经验的开发人员的建议，我一直将需要用户输入(表单处理、数据库管理等)的网页编码为自引用页面。对于 PHP 页面，我将表单的操作设置为 $_SERVER 预定义变量的 'PHP_SELF' 元素，并根据我传递给页面逻辑的参数确定要执行的代码块。

我喜欢所有代码都包含在一个文件中，而不是散布到各个结果页面。我发现的一个问题是我的统计解析程序无法区分页面的第一个 View 和后续 View (例如提交表单时)。很久以前，当我使用 CGI 或 CF 创建页面时，我将用户定向到一个不同的结果页面，该页面非常清晰地显示了该表单实际使用了多少次。

Web 开发中这些类型的页面的最佳实践是什么？使用(或不使用)自引用页面还有其他更有说服力的理由吗？

Answer 1

我认为，正如您所说，自引用页面没有遵循适当的关注点分离。您在同一个页面上做 2 件不同的事情，如果更清晰地分离逻辑，您可以在 2 个不同的页面上做它们。

MVC(模型- View - Controller ，http://en.wikipedia.org/wiki/Model-view-controller)框架强调了这种做法，例如 Ruby on Rails、Django 和 ASP.NET MVC(我不知道有什么 PHP ，尽管我确定有一些)。

这也是 RESTful(REpresentational State Transfer)实践的一个基本特征，其中每个 URL 代表一个资源和要对该资源执行的单个操作。另一方面，自引用页面的每个 URL/页面将有“2”个操作，例如“新建”(填写表单)和“创建”(实际创建对象)。

为网站实践 MVC 和 RESTful ( http://en.wikipedia.org/wiki/RESTful ) 实践通常会产生更清晰的代码和更好的关注点分离。这很重要的原因是它使测试更容易(我所说的测试是指单元和功能测试，而不是“在我的浏览器上尝试页面”测试)。

统计数据的困惑就是一个例子，说明不分离您的关注点会如何导致意想不到的复杂性。有些人可能会通过尝试检测请求的引荐来源网址来解决这个问题，并查看它是否是同一页面。这些实际上都只是解决症状的代码绷带，而不是解决问题。如果您在网站的不同页面中保留不同的“ Action ”，您可以将这些页面集中在他们的 1 个工作上，并确保他们做得很好，而不是用各种条件和额外的复杂性来混淆代码，如果1 个页面只有 1 个作业。