MVC-问题还是解决方案？

Repositories, Adapters, MVC with all it cousins, SOLID, RTFM… As a (PHP) developer, those words are thrown at you from every corner of the web. And I hate it, I’ve had enough. Stop telling me what to do and show me those kittens instead.

资源库，适配器，所有表亲的MVC，SOLID，RTFM…作为(PHP)开发人员，这些话从网络的各个角落扔给您。 我讨厌它，我受够了。 不要告诉我该怎么做，而是告诉我那些小猫。

软件解决问题 (Software solves problems)

We don’t just write software. Code doesn’t fall out of the sky into our files. We analyze the requirements, split them into small problems we know how to solve, and then we solve those small problems. Every line of code you write, have written and will ever write solves a certain problem. Be it to save the world, show kittens on a screen or make it look good in IE8. It’s there for a reason, don’t you touch it!

我们不只是编写软件。 代码不会掉入我们的文件中。 我们分析需求，将其分解为我们知道如何解决的小问题，然后解决这些小问题。 您编写，已经编写并且将要编写的每一行代码都可以解决某个问题。 无论是拯救世界，在屏幕上显示小猫还是使其在IE8中看起来都不错。 在那里是有原因的，你不碰它！

Problems are solvable and the solutions for these problems become part of something bigger. A black box that satisfies all initial requirements. But how do we solve these problems? Is my solution the best solution? Will other developers (or me in 2 months) understand what I did here?

问题是可以解决的，这些问题的解决方案已成为更大问题的一部分。 满足所有初始要求的黑匣子。 但是我们如何解决这些问题呢？ 我的解决方案是最好的解决方案吗？ 其他开发人员(或两个月后的我)会理解我在这里所做的事情吗？

一种解决方案适合所有人 (One solution fits all)

When solving the web-application problem, we are forced to use MVC. The dev community often frowns upon those who don’t use it, but seldom lets those they’re frowning upon ask why.

解决Web应用程序问题时，我们被迫使用MVC。 开发人员社区经常对那些不使用它的人皱眉，但是很少让他们皱眉的人问为什么。

So why is MVC the best? Commonly regurgitated reasons are:

那么为什么MVC最好呢？ 普遍反驳的原因有：

• Reduced Code complexity
  降低代码复杂度
• Code reuse
  代码重用
• Increased flexibility
  增加灵活性
• Decoupled code
  解耦代码

Cool, sounds nice, but…

很酷，听起来不错，但是…

• Is it true?
  是真的吗
• Do all other patterns lack these cool things?
  是否所有其他模式都缺少这些很棒的东西？

The answer is no.

答案是不。

MVC doesn’t solve the Code complexity problem. It doesn’t solve the code reuse or no-flexibility problem either. And it doesn’t guarantee decoupled code.

MVC不能解决代码复杂性问题。 它也不能解决代码重用或灵活性问题。 并且它不能保证解耦的代码 。

Developers guarantee reduced code complexity. It’s us coders, programmers, developers and artists that write flexible, decoupled and reusable code. We need MVC as much as we need jQuery for document.getElementById(). We’ve been building great software before anyone had heard of MVC and we will continue building great stuff without MVC.

开发人员保证降低代码复杂性。 是由我们的编码人员，程序员，开发人员和美术人员来编写灵活，解耦和可重用的代码。 对于document.getElementById()，我们与jQuery一样需要MVC。 在没有人听说过MVC之前，我们一直在开发出色的软件，如果没有MVC，我们将继续开发出色的产品。

Don’t forget that MVC is a pattern, not a solution. It stands in line with all the others. Adapters, Factories, Singletons, Modules, Interpreters, Observers…

不要忘记，MVC是一种模式，而不是解决方案。 它与所有其他观点一致。 适配器，工厂，单例，模块，口译员，观察员…

模式不能解决问题，它们可以帮助我们 (Patterns don’t solve problems, they help us)

Patterns help us write flexible, decoupled and easy to use code. A pattern is a best practice that a developer can use to solve problems. Those best practices vary depending on the type of problem you are solving, there is no top 5. A boat might be really good at crossing water, but it can’t plough a field.

模式可以帮助我们编写灵活，分离和易于使用的代码。 模式是开发人员可以用来解决问题的最佳实践 。 这些最佳做法因要解决的问题类型而异，没有前5名 。 船也许真的很擅长过水，但不能耕田。

Each pattern has its strength and weaknesses and is tailored to tackle a certain situation. The Factory pattern for instance is really good at creating Objects. The Module pattern helps us write software modules in a language that doesn’t (or only partially) support modules (e.g. JavaScript). The Observer pattern’s strength is event handling and MVC helps us in decoupling layout, data manipulation and controllers.

每种模式都有其优点和缺点，并针对特定情况进行了量身定制。 例如，Factory模式非常擅长创建对象。 模块模式有助于我们使用不(或仅部分)不支持模块(例如JavaScript)的语言来编写软件模块。 观察者模式的优势在于事件处理，MVC帮助我们解耦布局，数据操作和控制器。

But MVC is heavily abused, and here is why:

但是MVC被严重滥用，原因如下：

Somewhere down the road, someone decided that this was the best approach for everything written in PHP and accessible with a browser. Then came along the rule that a Model should have a 1-on-1 relation to a row in a database, Controllers should be thin and views have to be written in a templating language that compiles to PHP.

有人认为这是用PHP编写并可以通过浏览器访问的所有内容的最佳方法。 然后遵循以下规则：模型应与数据库中的一行具有一对一的关系，控制器应较薄，视图必须以可编译为PHP的模板语言编写。

Then, someone noted that ‘thin controller’ is not always the best approach. They thus created the rule of fat controller, thin model.

然后，有人指出“瘦控制器”并不总是最好的方法。 因此，他们创建了胖控制器规则，瘦模型。

Several iterations later, we made poor MVC give birth to HMVC, MVA, MVP, MVVM, PAC…

经过几次迭代，我们使不良的MVC产生了HMVC，MVA，MVP，MVVM，PAC ...

MVC是新的Singleton(或IE8) (MVC is the new Singleton (or IE8))

Sadly enough, MVC isn’t the only abused pattern. As Keith nicely points out:

令人遗憾的是，MVC并不是唯一被滥用的模式。 正如Keith很好地指出的那样：

We needed something that looked like a global and acted like a global but wasn’t really a global.

我们需要的东西看起来像是全球性的，而行为却像全球性的，但并不是真正的全球性。

Suddenly the Singleton pattern was showing up everywhere in our code. You could write crappy code without people complaining about the use of global $var. Instead we used the Singleton pattern, Global::getInstance()->var and called it OO.

突然，在我们的代码中到处都有Singleton模式。 您可以编写糟糕的代码，而不会有人抱怨使用global $var 。 相反，我们使用Singleton模式Global::getInstance()->var并将其称为OO。

模式很酷，开发人员却不 (Patterns are cool, developers aren’t)

Don’t get me wrong, patterns are there to be used. But use them wisely. Use them together. There is nothing worse then a developer using the wrong pattern for the wrong reason with the wrong intentions.

不要误会我的意思，这里有一些模式可以使用。 但是要明智地使用它们。 一起使用。 没有比这更糟糕的事情了，那就是开发人员出于错误的意图和错误的意图而使用了错误的模式。

So please, I beg you. Don’t abuse patterns.

所以求求你，我求求你 不要滥用模式。

Don’t reinvent the wheel. You are not the first developer trying to create modules in JavaScript, neither are you the first one developing event handling software. A lot of smarter, more trained professionals have done the exact same thing before you.

不要重新发明轮子。 您不是第一个尝试使用JavaScript创建模块的开发人员，也不是第一个开发事件处理软件的开发人员。 在您之前，许多更聪明，训练有素的专业人员都做过完全相同的事情。

Having trouble separating your MySQL from your PHP? Are you writing SELECT * FROM in your HTML? MVC will probably help you, or maybe Multitier architecture is a better fit for you.

无法将MySQL与PHP分开？ 您在用HTML编写SELECT * FROM吗？ MVC可能会为您提供帮助，或者也许多层体系结构更适合您。

Having troubles with lazy loading/reading config data? Singleton could help here.

延迟加载/读取配置数据有麻烦吗？ 辛格尔顿可以在这里提供帮助。

Is creating an object of a certain class a pain in the ass? The factory pattern can really help you stay DRY.

创建特定类别的对象会给您带来痛苦吗？ 工厂模式确实可以帮助您保持干燥。

Having troubles getting 2 services to communicate with each other? Adapters can help.

无法获得2种服务进行相互通信吗？ 适配器可以提供帮助。

结论 (Conclusion)

Depending on the situation, and the problem at hand, different patterns can help you write robust, secure and understandable code. Just be careful using them – if you catch yourself using the MVC pattern for a 1-pager, ctrl+a del.

根据情况和当前的问题，不同的模式可以帮助您编写健壮，安全和可理解的代码。 请小心使用它们-如果您将MVC模式用于1页，请使用ctrl+a del 。

May the patterns be with you!

愿模式与你同在！

翻译自: https://www.sitepoint.com/mvc-problem-solution/