核心概念 # 1、依赖注入篇 ~~~ 关注点分离：每一个类都应该是单一职责的，并且这个职责应该完全被这个类封装 ~~~ 「Web控制器」的职责就是真实应用的传输层：仅负责收集用户请求数据，然后将其传递给处理方。 因此，以后开发代码就别再将控制器和 ORM 耦合在一起了 【实现方式】IOC 控制反转：先定义接口，然后，把接口实例，注入导类中。 ~~~ 首先，我们来定义一个接口，然后实现该接口。 interface UserRepositoryInterface { public function all(): array; } class DbUserRepository implements UserRepositoryInterface { public function all(): array { return User::all()->toArray(); } } 然后，我们将该接口的实现注入到我们的控制器。 class UserController extends BaseController { public function __construct(UserRepositoryInterface $users) { $this->users = $users; } public function getIndex() { $users=$this->users->all(); return View::make('users.index', compact('users')); } } ~~~ ~~~ 严守边界：始终牢记保持明确的责任边界，控制器和路由是作为 HTTP 和应用程序之间的中介者来提供服务的（用户浏览应用的时候，路由/控制器作为中介将其引导到对应的服务）。当编写大型应用程序时，不要将你的领域逻辑混杂在控制器或路由中。 ~~~ # 2、# 服务容器篇 IoC 容器：控制反转容器让依赖注入更方便，它负责在整个应用生命周期内解析和注入那些定义在容器中的类和接口。 你可以把服务容器看作 IoC 容器在 Laravel 框架中的方言别名，两者等价。 这个服务容器就是个用来注册各种接口与实现绑定的地方。 Laravel 服务容器中最强大的功能之一就是通过反射来自动解析类的依赖。反射是一种在运行时检查类和方法的能力。 当 Laravel 的服务容器中没有某个显式绑定类的解析器时（即没有注册接口与对应实现的绑定），将会尝试使用反射来解析。程序流程类似于下面这样： 1. 已经有一个`StripBiller`的解析器了吗？ 2. 没有？那用反射来检查一下`StripBiller`吧，看看它有没有依赖。 3. 解析`StripBiller`需要的所有依赖（递归处理）。 4. 使用`ReflectionClass->newInstanceArgs()`来创建一个新的`StripBiller`实例。 # 3、# 接口篇 接口实际上并不做任何事情。它只是简单的定义了实现类必须拥有的一系列方法。 接口即纲领：接口有助于开发应用所提供的、已定义好的功能「框架」。 在组件的设计阶段，团队里使用接口进行讨论是很方便的，例如，定义一个`接口，然后讨论它提供哪些方法。在编写任何实现代码前，最好先通过接口讨论达成一致，这是构建一套好 API 的必要前提！ # 4、# 服务提供者篇 Laravel 服务提供者主要用来进行注册服务容器绑定（即注册接口及其实现类的绑定 #5 、#「SOLID」的设计原则，指面向对象编程和面向对象设计的五个基本原则： * 单一职责原则（Single Responsibility Principle） * 开放封闭原则（Open Closed Principle） * 里氏替换原则（Liskov Substitution Principle） * 接口隔离原则（Interface Segregation Principle） * 依赖反转原则（Dependency Inversion Principle） 单一职责原则规定一个类有且仅有一个理由使其改变。换句话说，一个类的边界和职责应当是十分狭窄且集中的。我们之前就提到过，在类的职责问题上，无知是福。一个类应当做它该做的事，并且不应当被它的任何依赖的变化所影响 开放封闭原则，又称开闭原则，规定代码对扩展是开放的，对修改是封闭的 要小心那些泄露实现细节的依赖。当一个依赖的实现需要改变时，不应该要求它的调用者做任何修改。如果需要调用者进行修改的话，往往意味着该依赖「泄露」了实现的细节。当你的抽象泄露时，开放封闭原则就不管用了。 一个抽象的任意实现都可以在声明该抽象的地方替换它。读起来有点绕口，通俗点说就是个：如果一个类使用了某个接口的实现，那么一定可以通过该接口的其它实现来替换它，不用做出任何修改。里氏替换原则规定对象可以被其子类的实例所替换，并且不会影响到程序的正确性 依赖反转原则，它规定高层次的代码不应该依赖低层级的代码。换句话说，高层次的代码应该依赖抽象接口，抽象接口就像是「中间人」一样，负责连接着高层次和低层次代码。这个原则的另一层意思是，抽象接口不应该依赖具体实现，但具体实现应该依赖抽象接口