vs2017安装mvc框架_2017年PHP MVC框架的现状

vs2017安装mvc框架

This article was first published on ZenOfCoding, and re-published here with the author’s permission.

本文最初在ZenOfCoding上发布 ，并在作者许可下在此处重新发布。

---

---

A simple question prompted me to sit down and write this follow up to my article from about a year ago.

一个简单的问题促使我坐下来，并将其写成大约一年前的后续文章 。

Q: Any thoughts about where things are today? (2/24/2017)

问：对今天的情况有什么想法？ (2/24/2017)

A: “I’d say it’s pretty much down to Laravel and Symfony at this point; when it comes to PHP frameworks. I don’t feel that there is any specific value to using CakePHP, Zend, CodeIgniter, Yii, etc. if you are starting a new project.

答： “我想说，这很大程度上取决于Laravel和Symfony。 当涉及到PHP框架时。 如果您开始一个新项目，我认为使用CakePHP，Zend，CodeIgniter，Yii等没有任何特定的价值。

Only if you already know those frameworks or have developers that are used to working with them, I could see a reason to use them.

只有在您已经了解那些框架或拥有习惯于使用它们的开发人员的情况下，我才能看到使用它们的理由。

When real development starts you have to be able to find tools, plugins, answers to common problems. And with Laravel and Symfony communities and constant development of new “modules” or features, you never feel like you’re left behind. Laracasts alone (even if you don’t develop in Laravel) are simply fantastic.

当真正的开发开始时，您必须能够找到工具，插件，常见问题的答案。 借助Laravel和Symfony社区以及不断开发新的“模块”或功能，您永远不会感到自己落伍了。 单独使用Laracast(即使您不使用Laravel进行开发)也很棒。

Whether it’s integration with services like iron.io or other SaaS providers, support for a wide variety of data-sources, local dev env like Homestead, these frameworks and supporting modules are much more forward driven.

无论是与iron.io等服务集成还是其他SaaS提供商，对各种数据源的支持，像Homestead这样的本地开发环境，这些框架和支持模块都具有更强的前瞻性。

Complimented by Lumen for quick API development Laravel really shines as a great approach to rapid application development and prototyping nowadays. Not to say that it’s somehow limited [when it comes to building] larger applications.

由Lumen赞扬，可以快速进行API开发Laravel确实是当今快速进行应用程序开发和原型制作的绝佳方法。 并不是说在构建大型应用程序时，它受到某种程度的限制。

Generally speaking, however, we’re definitely seeing a shift towards a container-based architecture, where MVC plays a much lesser role. It’s all about microservices, orchestration and building apps as “functions” (i.e. AWS Lambda and similar services). Perhaps it’s time to brush up on your Node/JS and GoLang skills :)”

但是，总的来说，我们肯定会看到向基于容器的体系结构的转变，其中MVC的作用要小得多。 这一切都与微服务，业务流程和将应用程序构建为“功能”(即AWS Lambda和类似服务)有关。 也许是时候锻炼一下您的Node / JS和GoLang技能了：)”

Although I felt generally happy with this answer, I couldn’t help thinking that elaborating on some of these points and taking a fresh look at where things are would be a good idea.

尽管我对这个答案总体上感到满意，但是我不禁想到，详细阐述其中的一些要点并重新审视事物的发展是一个好主意。

Before I jump into the strange topics like “GoLang”, let’s actually take a step back and glance at the trends in 2017, in the PHP MVC Frameworks World.

在我进入诸如“ GoLang”之类的奇怪话题之前，让我们先退后一步，回顾一下PHP MVC Frameworks World中的2017年趋势。

I would say that the trends we’ve observed in the past are holding up. Laravel is still pushing forward, while most everyone else is falling behind. There is a little uptick in Symfony popularity, probably due to the much awaited release of Symfony 3.

我要说的是，我们过去观察到的趋势正在保持。 Laravel仍在前进，而其他大多数人都落后。 Symfony的流行度有所上升，这可能是由于期待已久的Symfony 3的发布。

(I have tried more specific searches for comparison such as “CakePHP 3”, or “ZF2”, however those did not produce statistically significant trends).

(我尝试使用更具体的搜索进行比较，例如“ CakePHP 3”或“ ZF2”，但是这些搜索并没有产生统计学上的显着趋势)。

This year I’ve included CodeIgniter because it is very popular, as evident. I received a number of questions about CodeIgniter and my thoughts on where it stands in the PHP MVC community… Well to keep it short, CI is still out of the competition because it’s not a true MVC framework. I don’t know what to call it other than an organized collection of POPO’s …

显而易见，今年我加入了CodeIgniter，因为它非常受欢迎。 我收到了许多有关CodeIgniter的问题，以及我对它在PHP MVC社区中的地位的看法……简而言之，CI仍然是竞争对手，因为它不是真正的MVC框架。 除了POPO的有组织集合之外，我不知道该怎么说。

Let’s just take this quote directly from their manual:

让我们直接从他们的手册中引用此报价：

CodeIgniter has a fairly loose approach to MVC since Models are not required. If you don’t need the added separation, or find that maintaining models requires more complexity than you want, you can ignore them and build your application minimally using Controllers and Views.

因为不需要模型，所以CodeIgniter对MVC的方法相当宽松。 如果您不需要额外的分隔，或者发现维护模型所需的复杂性超出了您的期望，则可以忽略它们，并使用Controllers和Views最少地构建应用程序。

When it comes to building a framework I simply disagree with this approach. Perhaps it’s a decent boilerplate, hence CodeIgniter’s popularity, however there must be some discipline enforced by the framework, otherwise the eventual product winds up being a mess of spaghetti code, wrapped into some sort of a “pattern”.

在构建框架方面，我完全不同意这种方法。 也许这是一个不错的样板，因此是CodeIgniter的流行，但是框架必须强制执行某些纪律，否则最终产品将变成一团意大利面条代码，被包装成某种“模式”。

Moving on, Symfony 3 brought us some decent improvements in developer experience, dependency injection and a number of other features. Like many PHP counterparts it now offers a micro-framework. ZF3, comparatively, delivered a set of improvements, like support for PHP7 (finally) and even a micro-framework of its own… but like their manual says:

继续前进，Symfony 3为我们带来了开发人员体验，依赖项注入和许多其他功能的一些不错的改进。 像许多PHP同行一样，它现在提供了微框架。 相对而言，ZF3进行了一系列改进，例如对PHP7的支持(最终)，甚至是其自身的微框架……但就像他们的手册所说：

For Zend Framework 2 MVC users, the differences are subtle…

对于Zend Framework 2 MVC用户而言，差异是细微的……

I was really hoping that they would say that the differences are dramatic, that there was some great architectural improvement, wonderful new modules that help you develop things in a modern way. Alas, for the most part ZF3 remains pretty similar to ZF2.

我真的希望他们能说出差异是巨大的，对体系结构进行了一些巨大的改进，提供了许多很棒的新模块来帮助您以现代方式进行开发。 las，在大多数情况下，ZF3仍与ZF2非常相似。

长话短说 (Long Story Short)

Here’s how I see the world of PHP frameworks today:

这就是我今天看到PHP框架世界：

1. Symfony or Laravel, depending on your needs
   Symfony或Laravel，取决于您的需求
2. The rest
   其余的部分

Hands down, Laravel stole the show. The amount of information available, Laracasts, world wide developer talent, simple pattern implementations, integrated testing toolsets, active record implementation in the form of Eloquent, lightweight version in Lumen, local development using Homestead (Vagrant) make this framework really stand out for new and seasoned developers.

放下手，Laravel偷走了演出。 可用的信息量，Laracast，全球开发人员的才能，简单的模式实现，集成的测试工具集，以Eloquent形式进行的活动记录实现，流明的轻量级版本，使用Homestead(Vagrant)进行本地开发，使该框架真正在新的应用中脱颖而出和经验丰富的开发人员。

However Eloquent models can get unruly and rather large in size, too many Laravel services may be created (not to be confused with microservices) and people start thinking about Repository pattern implementation where it doesn’t belong. Thus a Monolith is born.

但是，雄辩的模型可能变得不规则且规模很大，可能会创建过多的Laravel服务(不要与微服务混淆)，人们开始考虑不属于它的 Repository模式实现。 这样，巨石诞生了。

If you are not comfortable with the active record pattern and need the added flexibility of Repositories, or perhaps you’re seeing too many anonymous functions for your liking, then use Symfony + Doctrine. Do I consider Symfony a gateway to monolithic applications? To some degree, yes. However, it is probably the most elegant one.

如果您对活动记录模式不满意并且需要增加存储库的灵活性，或者您可能喜欢使用太多匿名函数，请使用Symfony + Doctrine。 我是否认为Symfony是通向整体应用程序的网关？ 在某种程度上，是的。 但是，它可能是最优雅的一种。

Overall, I would not call it a drastic change from the last year. Still, we need to take a look at the bigger picture: a properly designed application goes beyond just MVC; it’s about infrastructure, deployment pipeline, decoupled architecture. All of these can be achieved in an MVC stack, but one needs to be extra mindful to avoid the Monolith.

总体而言，与去年相比，我不会说它发生了巨大变化。 尽管如此，我们仍然需要从更大的角度看待：一个经过适当设计的应用程序不仅限于MVC；还包括其他一些功能。 它涉及基础架构，部署管道，分离的架构。 所有这些都可以在MVC堆栈中实现，但是需要特别注意避免使用Monolith。

微服务的到来 (Advent of Microservices)

Earlier I’ve alluded to the rise of the microservices and the need to brush up on GoLang or Node skills. Indeed, even in the PHP MVC article it would be silly not to mention a clearly happening move towards microservice oriented architecture (MOA); and it’s gaining momentum like you wouldn’t believe it.

之前，我曾提到微服务的兴起以及对GoLang或Node技能的重新学习。 确实，即使在PHP MVC文章中，也没有提到明显发生的朝着面向微服务的体系结构(MOA)的转变是很愚蠢的。 就像您不相信它一样，它正在获得动力。

While the two concepts are not mutually exclusive there’s no reason trying to find parallels between the two, as they really do represent different, albeit intersecting philosophies.

尽管这两个概念不是互相排斥的，但没有理由试图在两者之间找到相似之处，因为它们确实代表了不同但相互交叉的哲学。

As an example, putting your MVC app in one container and MySQL in another and then linking them together, doesn’t necessarily represent a proper MOA. This is certainly a better approach, in fact much better, than trying to install MAMP, XAMPP or whatever other clutter you need in order to get your local machine to serve an application.

例如 ，将MVC应用程序放在一个容器中，然后将MySQL放在另一个容器中，然后将它们链接在一起，并不一定代表正确的MOA。 与尝试安装MAMP，XAMPP或您需要的其他杂物以使本地计算机为应用程序服务相比，这无疑是一种更好的方法，实际上要好得多。

Additionally, it may solve some issues like ease of running a local environment across different platforms (developers) and perhaps deployment strategy, in some cases, but you are stuck with an MVC Monolith in your app layer/container.

此外，在某些情况下，它可以解决一些问题，例如在不同平台(开发人员)之间运行本地环境的难易程度，以及部署策略，但是，您在应用程序层/容器中受制于MVC Monolith。

巨石的破坏 (Destruction of the Monolith)

This “destruction” is what microservices are all about. While MVC addresses your code structure and organization by providing a solid approach to the separation of concerns, this concept is extended even further by the containers/services/MOA.

这种“破坏”就是微服务的全部意义所在。 虽然MVC通过提供一种可靠的关注点分离方法来解决您的代码结构和组织问题，但是容器/服务/ MOA进一步扩展了此概念。

Instead of just separating your views from your models, you are now separating each “chunk” or logical unit of your application into an individual service, designed to properly handle its own responsibilities.

现在，您不仅要从模型中分离视图，还需要将应用程序的每个“块”或逻辑单元分离到一个单独的服务中，以正确处理自己的职责。

If your MVC app has a “Search” controller, action, and relevant Model methods, then we already have an example of a monolithic application.

如果您的MVC应用程序具有“搜索”控制器，操作和相关的Model方法，那么我们已经有一个整体应用程序的示例。

In contrast, using MOA approach, we’d have a service for each one of those processing units. As an example:

相反，使用MOA方法，我们将为每个处理单元提供服务。 举个例子：

• Router Service
  路由器服务
• Request Service
  要求服务
• Query Service
  查询服务
• DataSource Service
  数据源服务
• Response Service
  响应服务

Wait, but aren’t all those “services” are just a part of an MVC stack. Well, yes, exactly. They are the building blocks of our Monolith.

等等，但并非所有这些“服务”都只是MVC堆栈的一部分。 好吧，是的。 它们是我们Monolith的基础。

With MOA each service runs within its own environment, and as developers, but more so as architects we are free to design the best approach to solving a specific need.

借助MOA，每个服务都可以在自己的环境中运行，并且可以作为开发人员运行，而对于架构师而言，则更多，我们可以自由设计最佳方法来解决特定需求。

As an example if I were to write an Image Processing Service within a Laravel environment, I’d probably be using something like PHP-GD2 extension, which may not be the most efficient way to process images. A C++ service that handles my needs of image processing, may be a lot faster and definitely more robust at scale. To elaborate even more we could now take the output of the Image Processing Service and send it off to DataStore Service, CloudStorage Service and Queue Email Service.

例如，如果我要在Laravel环境中编写图像处理服务，则可能会使用PHP-GD2扩展之类的东西，这可能不是处理图像的最有效方法。 满足我的图像处理需求的C ++服务可能更快，更可靠。 为了进一步详细说明，我们现在可以获取图像处理服务的输出，并将其发送给数据存储服务，CloudStorage服务和队列电子邮件服务。

Solving this same challenge with a bunch of cron jobs and possibly a couple of separate MVC apps and custom scripts is how we did things back in the day (i.e. 2 years ago). Time to move forward.

通过一堆cron作业以及可能需要几个单独的MVC应用程序和自定义脚本来解决相同的挑战，这就是我们在一天中(即2年前)所做的事情。 是时候前进了。

可扩展性 (Scalability)

This is where the problems start (or end, depending on where you are headed). On one hand it’s hard to scale a Monolith, if you build more and more logic into the same MVC stack you’ll be stuck with, perhaps, a well structured application of horrendous complexity.

这是问题开始的地方(或结束的地方，具体取决于您要去的地方)。 一方面，很难扩展Monolith，如果您在同一个MVC堆栈中构建越来越多的逻辑，那么您可能会被困在结构复杂，复杂性极高的应用程序中。

On the other hand if you build a thousand microservices in a variety of languages, how do yo manage THAT mess?

另一方面，如果您使用多种语言构建了上千种微服务，那么您将如何管理混乱的局面？

There is more than one disaster that has been reported.

有 不止一个 的灾难已报道 。

There are various container orchestration tools (like Kubernetes, Swarm, Mesos), container deployment services (i.e. GKE and AWS ECS), however few enterprises have nailed the Docker architecture. There are definitely success stories in building out of the infrastructure using Docker or other container technologies (i.e. GKE). Most of these stories come from companies that can afford to spend resources on architects, devops, DBA’s and engineers. Still, as it stands now there are countless debates about how to deploy a well orchestrated and elegant MOA. One size definitely does not fit all in this case and there is a multitude of ways to solve your challenge.

有各种各样的容器编排工具(例如Kubernetes，Swarm，Mesos)，容器部署服务(例如GKE和AWS ECS)，但是很少有企业采用Docker架构。 在使用Docker或其他容器技术(即GKE)构建基础架构方面肯定有成功的故事。 这些故事大多数来自有能力在架构师，开发人员，DBA和工程师上花费资源的公司。 尽管如此，就目前而言，关于如何部署精心组织和优雅的MOA仍存在无数争论。 在这种情况下，一种尺寸绝对不能满足所有需求，并且有多种方法可以解决您的挑战。

Either way you’re not going to solve this problem alone (DevOps FTW!), and not until you’ve hit a relatively massive scale, will this problem actually need solving. Maybe it’s not the right time to over-engineer.

无论哪种方式，您都不会单独解决此问题(DevOps FTW！)，并且直到您达到一个相对较大的规模时，此问题才真正需要解决。 也许现在不是过度工程的正确时机。

A happy middle for today (and for those that deal with apps of lesser complexity or traffic requirements) is to offload many typical services to third party providers. Almost everything is available as service now. Background jobs, image processing, authentication, data analytics, logging, email sending, queue systems need not be built within the same MVC stack, rather an Architect should think about what could be offloaded to a SaaS system for a low monthly cost (i.e. search by Algolia) or perhaps a custom-built docker service running in some cloudy space, which handles that annoying image processing.

对于当今(以及那些处理复杂性或流量要求较低的应用程序的人)来说，一个快乐的中途是将许多典型的服务分流给第三方提供商。 现在几乎所有内容都可以作为服务使用。 后台作业，图像处理，身份验证，数据分析，日志记录，电子邮件发送，队列系统无需在同一MVC堆栈内构建，而是架构师应考虑可以以较低的每月成本(即搜索)将哪些内容分流到SaaS系统中由Algolia提供)或运行在多云空间中的自定义docker服务，该服务可处理令人讨厌的图像处理。

I guess the point here is that you should not jump into a re-architecture project head first, do not dump everything you have today, and release docker swarms wherever imaginable. There are ways to gradually roll out an improved foundation by decoupling what’s possible, learning about bottlenecks in the system and applying the notion of separation of concerns to these problem areas.

我想这里的要点是，您不应该首先跳入重新架构项目的负责人，不要转储您今天拥有的所有内容，并在可能的范围内释放docker swarms。 通过分离可能的方式，了解系统中的瓶颈并将关注点分离的概念应用于这些问题区域，有一些方法可以逐步推出改进的基础。

结论 (Conclusion)

2017 is going to bring us more conversations and production deployments of container-based and MOA. My points and ramblings about Docker, using GoLang or Node, do not mean that PHP is “dying” or anything of that sort … I feel that as developers we need to stay on the cutting edge of things, so if microservices is where it’s at, then why not learn GoLang? It is ideally suited (due to low footprint, speed and parallel processing) for developing tiny containerized apps. Node and GoLang are fun because they allow you to build little services, who are all part of a larger tribe, link them together, and release them as an epic swarm of Docker containers if you so desire. Yet, all this awesomeness and cutting edge solutions and languages does not mean that PHP is somehow no longer relevant or is otherwise “dead”. We’re definitely going to be building MVC stacks and API endpoints for a while.

2017年将为我们带来更多有关基于容器和MOA的对话和生产部署。 我对使用GoLang或Node的Docker的观点和观点并不代表PHP即将“消亡”或类似的东西……我认为，作为开发人员，我们需要始终站在最前沿，因此，如果微服务在这里，那为什么不学习GoLang？ 由于占用空间小，速度快和并行处理，它非常适合开发微型容器化应用程序。 Node和GoLang很有趣，因为它们允许您构建很少的服务，这些服务都是较大部落的一部分，将它们链接在一起，并根据需要将它们作为Docker容器的史诗群发布。 然而，所有这些出色的解决方案和最先进的解决方案和语言并不意味着PHP不再具有某种意义，或者说是“过时的”。 我们肯定会在一段时间内构建MVC堆栈和API端点。

One of the issues, which has not been solved by MOA, is that while containers help us to kill the Monolith on the backend we are still faced with many architectural issues in our front-end layer, UI or the view. We can build an awesomely robust backend application, but in the end it will respond with a JSON, which somehow must be rendered in the client application. Does it matter if the eventual response object arrives from a simple PHP, let’s say, Lumen driven endpoint (URL) or an orchestra of decision making and processing units decoupled by a messaging interface? This, indeed, very much depends on your needs and the requirements of your application.

MOA尚未解决的问题之一是，尽管容器可以帮助我们杀死后端的Monolith，但我们在前端层，UI或视图中仍然面临许多架构问题。 我们可以构建一个功能强大的后端应用程序，但最终它将使用JSON响应，该JSON必须以某种方式呈现在客户端应用程序中。 最终的响应对象是否来自简单PHP(例如流明驱动的端点(URL)或由消息传递接口解耦的决策和处理单元的乐队)，这有关系吗？ 实际上，这在很大程度上取决于您的需求和应用程序的要求。

For this year, learn Laravel keep an eye on Docker, GoLang and definitely focus on the deployment pipeline. Getting from local to production should be smoother than it has been for a while now, especially when building your MVC apps.

在今年，学习Laravel密切关注Docker，GoLang，并绝对专注于部署管道。 从本地到生产的过渡应该比现在要平稳一些，尤其是在构建MVC应用程序时。

翻译自: https://www.sitepoint.com/the-state-of-php-mvc-frameworks-in-2017/

vs2017安装mvc框架