From Apprentice To Artisan 翻译 10

上一篇

Application Structure 应用结构

Introduction 介绍

Where does this class belong? This question is extremely common when building applications on a framework. Many developers ask this question because they have been told that "Model" means "Database". So, developers have their controllers that interact with HTTP, models which do something with the database, and views which contain their HTML. But, what about classes that send e-mail? What about classes that validate data? What about classes that call an API to gather information? In this chapter, we'll cover good application structure in the Laravel framework and break down some of the common mental roadblocks that hold developers back from good design.

这个类要写到哪儿？这是一个在用框架写应用程序时十分常见的问题。大量的开发人员都有这个疑问。他们被灌输“Model”就是“Database”，在控制器里面处理HTTP请求，在模型里操做数据库，视图里包含了要显示的HTML。不过，发送电子邮件的类要写到哪儿？数据验证的类要写到哪儿？调用外部API的类要写到哪儿？在这一章节，咱们将学习如何写结构优美的Laravel应用，打破长久以来掣肘开发人员的广泛思惟惯性这个拦路虎，最终作出好的设计。

MVC Is Killing You MVC是慢性谋杀

The biggest roadblock towards developers achieving good design is a simple acronym: M-V-C. Models, views, and controllers have dominated web framework thinking for years, in part because of the popularity of Ruby on Rails. However, ask a developer to define "model". Usually, you'll hear a few mutters and the word "database". Supposedly, the model is the database. It's where all your database stuff goes, whatever that means. But, as you quickly learn, your application needs a lot more logic than just a simple database access class. It needs to do validation, call external services, send e-mails, and more.

为了作出好的程序设计，最大的拦路虎就是一个简单的缩写词：M-V-C。模型、视图、控制器主宰了Web框架的思想已经好多年了。这种思想的流行某种程度上是托了Ruby on Rails越发流行的福。然而，若是你问一个开发人员“模型”的定义是什么。一般你会听到他嘟哝着什么“数据库”之类的东西。这么说，模型就是数据库了。无论这意味着什么，模型里包含了关于数据库的一切。可是，你很快就会知道，你的应用程序须要的不单单是一个简单的数据库访问类。他须要更多的逻辑如：数据验证、调用外部服务、发送电子邮件，等等更多。

What Is A Model? 模型是啥？

The word "model" has become so ambiguous that it has no meaning. By developing with a more specific vocabulary, it will be easier to separate our application into smaller, cleaner classes with a clearly defined responsiblity.

单词"model"的含义太模糊了，很难说明白准确的含义。更具体来说，模型是用来将咱们的应用划分红更小、更清晰的类，使得各代码部分有着明确的权责。

So, what is the solution to this dilemma? Many developers start packing logic into their controllers. Once the controllers get large enough, they need to re-use business logic that is in other controllers. Instead of extracting the logic into another class, most developers mistakenly assume they need to call controllers from within other controllers. This pattern is typically called "HMVC". Unfortunately, this pattern often indicates poor application design, and controllers that are much too complicated.

因此怎么解决这个问题（译者注：上文中“更多的业务逻辑”）呢？不少开发者开始将业务逻辑包装到控制器里面。当控制器庞大到必定规模，他们将会须要重用业务逻辑。大部分开发人员没有将这些业务逻辑提取到别的类里面，而是错误的臆想他们须要在控制器里面调用别的控制器。这种模式一般被称为“HMVC”。不幸的是，这种模式一般也预示着糟糕的程序设计，而且控制器已经太复杂了。

HMVC (Usually) Indicates Poor Design

HMVC（一般）预示着糟糕的设计。

Feel the need to call controllers from other controllers? This is often indicative of poor application design and too much business logic in your controllers. Extract the logic into a third class that can be injected into any controller.

你以为须要在控制器里面调用其余的控制器？这一般预示着糟糕的程序设计而且你的控制器里面业务逻辑太多了。把业务逻辑抽出来放到一个新的类里面，这样你就能够在其余任何控制器里面调用了。

There is a better way to structure applications. We need to wash our minds clean of all we have been taught about models. In fact, let's just delete the model directory and start fresh!

有一种更好的程序结构。但首先咱们要忘掉以往咱们被灌输的关于“模型”的一切。干脆点，让咱们直接删掉model目录，从新开始吧！

下一篇