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目錄，從新開始吧！

下一篇