MVC 现在是编写 PHP 的唯一方法吗?

发布于 2024-10-09 06:36:37 字数 1459 浏览 2 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

┾廆蒐ゝ 2024-10-16 06:36:37

我不喜欢有人告诉我如何编写代码。如果我想使用 MVC,我会,如果我找到解决特定任务的更好方法,我会使用它。我不喜欢人们把 MVC 变成一种宗教。我还认为许多 php 程序员误解了 MVC 概念,并认为他们正在使用 MVC 模式,而实际上大多数时候他们并没有使用 100% 纯 MVC。事实上,编写一个 100% MVC 且用 php 编写的网站并不容易,也不是很高效。

大多数人在 MVC 的“V”部分遇到最多的困难。 “M”很简单。这是你的数据。如果您将数据存储在数据库中并具有数据库访问类,那就是您的“M”部分,您可以使用“M”

现在控制器:当用户单击页面的任何链接时,您的php代码必须从“M”(数据库),准备它,应用一些逻辑,例如向登录用户添加个性化,如果用户未登录则添加“请登录”链接等。这是您的“C”部分。

大多数人遇到的问题是将“V”视图与“C”(控制器)分离,这并不容易,也不是在 php 中编码的最有效方法。在许多情况下,控制器部分必须已经生成一些 html,因此您模糊了控制器和视图之间的界限。

如果你想保持纯 MVC,那么你必须确保你的控制器返回纯数据,然后 View 类采用一些模板,插入你的数据并返回 HTML。这就是php的问题所在。没有简单有效的方法来进行模板化,其中模板仅将纯数据作为输入并返回 html。如果有一种简单的方法,那么人们就没有理由继续提出另一个新的模板库。 php 之所以有如此多的模板库,是因为总有程序员对任何现有的模板库都不满意,并不断尝试发明自己的更好的模板库。

在我看来,唯一的纯模板库是 XSLT,它完全受 php 支持,它随 php 一起提供,它可以工作,它是强大的、出色的模板引擎,更好的是,它是一种标准的、独立于平台的语言。一旦学习了 XSLT,您就可以在任何其他编程语言(如 Java)中使用它。但它确实有一个小问题。它要求输入是 XML。当然,您也可以使用 DOM 库在 php 中创建一个出色的、100% 有效的 XML,该库也是 php 的一部分。问题是它会很慢。您将做双倍的工作:首先从数据数组创建 XML,然后使用 XSL 模板将该 XML 转换为 HTML。这就是为什么 XSLT 作为模板引擎的方法从未在 php 中流行起来。

现在您留下了解析模板的其他选项,通常是基于正则表达式的方法。您知道当我们到达 MVC 的“V”部分时它总是变得复杂吗?

“M”很简单,“C”是某种类型的纯php代码,无论是OOP还是过程代码,都没关系。棘手的是“视图”。

所以我的建议是 - 不要太担心坚持纯 MVC。控制器可以到处吐出 html 块。

I don't like anyone telling me how to write a code. If I want to use MVC I will, if I find a better way that solves specific task, I will use it. I don't like when people turn MVC into a religion. I also think many php coders misunderstand the MVC concept and think they are using MVC pattern when in fact most of the times that are not using a 100% pure MVC. The truth is that it's not easy nor very efficient to write a website that is 100% MVC and is written in php.

Most people having most difficulties in the "V" part of the MVC. The "M" is easy. It's your data. If you storing your data in the database and have a database access class, that's your "M" part, you good with "M"

Now the controller: when user clicks on any link of your page, your php code must get the data from the "M" (database), prepare it, apply some logic like adding personalization to logged in user, adding "please login" link if user not logged it, etc. This is your "C" part.

The problem that most people are having with is separating the "V" View from "C" (controller) This is not easy nor is it the most efficient way to code in php. In many cases the controller part must already generate some html, so you blur the line between controller and view.

If you want to stay pure MVC then you must make sure that your controller returns a pure data, then the View class takes some template, plugs in your data and returns the HTML. This is where the problem lies in php. There is no easy and efficient way to do templating where a template just takes a pure data as input and returns the html. If there was an easy way, then there would not be reason for people to keep coming up with yet another new template library. The reason the there are so many templating libraries for php is because there are always programmers that are not happy with ANY of the existing ones and keep trying to invent their own, better one.

The only pure templating library in my opinion is the XSLT, which is fully supported by php, it's comes with php, it works, it's powerful, great templating engine, better yet, it's a standard, platform independant language. Once you learn XSLT you can use it in any other programming language like Java. But it does have one tiny problem, however. It requires the input to be an XML. Sure, you can create a great, 100% valid XML in php also using DOM library which is also part of php. The problem is that it will be slow. You will be doing double the work: first creating XML from your array of data, then trasforming that XML into HTML with your XSL template. This is why the approach of XSLT as templating engine never took off in php.

Now you left with the other options to parse templates, usually its regex based approach. You see how it always gets complicated when we get to the "V" part of the MVC?

The "M" is easy, the "C" is some type of pure php code, be it OOP or procedural code, does not matter. It's the "View" that is the tricky one.

So my advice is - don't worry too much about sticking to pure MVC. It's OK for a controller to spit out chunks of html here and there.

姐不稀罕 2024-10-16 06:36:37

还有很多其他方法。

MVC 之所以流行,是因为它适合大多数情况(或者更好地说可以在大多数情况下使用),并且已将自己确立为事实上的标准。

可以说的是,每个编程/设计模式 - 或者更具体的架构 - 都取决于某种分类。

这些通常是(当然它们可以进一步划分):

  • 用户界面(漂亮的图像、表单等)

  • 应用程序(您的应用程序逻辑和需要的东西 )保护客户端的安全 - 很多事情通常可以在用户界面中完成,例如通过 javascript)

  • 数据库 - 自我解释

  • 基础设施(非常基本的东西,如硬盘、服务器系统、网络等)

当然,总是有简单的、程序化的直接方法,但也有很多其他模式可以链接和构建对这些基本层的访问和控制。

Mvc就是其中之一。但以下是其他一些示例:

http://en.wikipedia.org/wiki/Model_View_ViewModel

http://en.wikipedia.org/wiki/Model_View_Presenter

MVC-ARS 是否比经典 MVC 更适合防止过载?

这里更多信息:

http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)< /a>

Well there are a lot of other approaches.

MVC is just popular because it suits most situations (or better said can be used in most situations) and has established itself as a de-facto standard.

What can be said is that every programming/design pattern - or more specific architectural - depends on some classification.

Those are often (of course they can be devided further):

  • User Interface (pretty images, forms etc)

  • Application (your application logic and stuff that needs to be secured from the client - ak lot of that can often be done in the user inteface, eg. by javascript)

  • Database - self explaining

  • Infrastructure (very basic stuff like hard disk, server systems, network etc.)

Of course there is always the naive, procedural straight-forward approach but also a lot fo other patterns that can link and structure the access and controlling to these basic layers.

Mvc is one of them. But here are some example of others:

http://en.wikipedia.org/wiki/Model_View_ViewModel

http://en.wikipedia.org/wiki/Model_View_Presenter

Is MVC-ARS preferable to classic MVC to prevent overloading?

And here a lot more:

http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文