cms网站建设实训报告,遵义酷虎网站开发,哪个网站做自考题目免费,暖暖 免费 视频 在线观看1文章目录 前言Phoenix的web层概念PlugEndpointRouterScopePipeline ControllerAction Component 一次请求 前言
Elixir和Phoenix的作者也是Rails社区的核心开发者#xff0c;如果是之前接触过Ruby on Rails的开发者#xff0c;对Phoenix也许不会感到太陌生。笔者没有接触过R… 文章目录 前言Phoenix的web层概念PlugEndpointRouterScopePipeline ControllerAction Component 一次请求 前言
Elixir和Phoenix的作者也是Rails社区的核心开发者如果是之前接触过Ruby on Rails的开发者对Phoenix也许不会感到太陌生。笔者没有接触过Ruby on Rails只能从Go语言的经验和角度出发去对比理解。如果说一开始Phoenix的确脱胎于Rails经过这么多版本的迭代加上Elixir的语法特点Phoenix也一定产生了一些特有的变化。上一期我们学习了Phoenix入门篇书接上回这次我们重点介绍下Phoenix框架中的一些概念并继续探索它的架构设计思想。希望本文能帮助你开始Phoenix开发之旅即便最后你决定不适用Phoenix它的架构思想也一定会对你有所启发。
首先我们来思考两个问题
网络框架要解决的核心问题是什么框架的核心价值是什么
相信每个人对这两个问题都有不同的见解下面也仅仅是我个人对这两个问题一些看法。
我们可以先简单的认为网络服务就是在反复做一件事接收请求返回响应。所谓请求就是一个网络资源它由一个网络路径标识。所以网络框架要解决的核心问题就是决定不同的路径应该由哪个函数来发出响应其实也就是要解决路由的问题。这一点Go标准库就做的十分纯粹所以用Go标准库来写一些小型的后端服务是非常简单惬意的。
那么纯粹的代价是什么呢这就是网络框架的核心价值问题。框架的核心价值是效率包括开发效率和维护成本。懂事的框架会帮你做许多琐碎的事让你可以专注于业务逻辑。比如日志监控等这些虽然不是核心功能但是对于一个线上系统来说又必不可少。其次框架会为你提供一套行为规范在你的项目越来越大时不会陷入混乱而不得不重构。代码生成也是一个好东西可以节省不少时间。此外框架的复杂程度和学习成本也值得考虑如果对于一个简单的服务也必须要先看完几百页的说明书才能把服务跑起来那么就要好好考虑一下这几百页的说明书值不值得看了。
另外扯一点题外话不要提前解决还未遇到的问题。不知道大家在看到网上哪些大谈架构或者起着牛逼哄哄标题的文章时会不会产生技术焦虑。事实上部分技术文章并不那么纯粹都是带着引流目的的。制造焦虑也是一种营销手段倒不是说不应该去学习然而我们首先要理解的是问题而不是技术本身。框架也好架构也好什么也好它们存在的意义是解决问题而不是带来问题或者说它们能解决的问题远大于其带来的问题。古人云任何事情都是有代价的。理解了问题才能对阵下药切勿乱投医。
言归正传在继续阅读之前希望你已经阅读过了Phoenix入门篇。需要说明的是本篇主要是介绍相关概念多是以生成项目时的初始代码为例也不会深入代码细节与写代码相关的细节我会在稍后的实战篇中介绍。
Phoenix的web层概念
Phoenix在v1.3版本对目录结构做了一次大的调整有了我们今天看到的结构。经过这次调整之后业务逻辑和web接口彻底分离。我们不再是开发一个以web为核心的应用而是开发一个具有web接口的系统。这有很么区别呢在以前端为核心的应用中我们很容易从前端出发去思考后端业务逻辑导致边界逐渐模糊逻辑慢慢往controller里面移动。但实际上我们应该首先考虑业务逻辑基于此来提web接口。
Phoenix也是一个MVC的框架它把MVC中的V和C抽到了web层构成了应用的web接口对应着 lib/hello_web 目录 hello 是你的项目名我们还是沿用Phoenix入门篇中的示例。
在web接口中Phoenix抽象出了plugendpointrouterscopepipelinecontrolleractioncomponent等概念它们的整体关系如下图所示。 Plug
Plug贯穿了整个Phoenix的web接口我们可以在web层的各个地方看到plug的身影。可以说Plug是Phoenix的核心理解Plug是理解Phoenix框架的关键。Plug既是一个抽象概念也有对应实体我们需要区分一下不同地方出现的plug的含义。
作为抽象概念Plug是一个连接转换器它接受一个连接经过一些处理最后返回一个连接。然后这个连接还可以交给下一个Plug继续处理构成一个连接转换的链条这正是Phoenix处理请求的核心机制。听起来有点像中间件虽然Phoenix的中间件也是通过Plug机制实现的但是Plug本身不同于我们所熟知的中间件概念这一点一定要分清。这里的“连接”指的是客户端连接用 %Plug.conn{} 结构体表示。你可以把它想象成糖葫芦连接就是竹签Plug就是竹签上的山楂。
Plug可以是一个函数也可以是一个模块。
如果是函数Plug第一个参数一定是 %Plug.conn{} 结构体第二个参数取决于应用Plug时传递的内容。第一个参数是Phoenix自动传入的稍后我们会介绍第二个参数是如何传递的。最后函数一定要返回一个 %Plug.conn{} 结构体。举个例子
def func_plug(conn, _opts) do# do somethingconn
end如果是模块Plug需要定义两个函数 init/1 和 call/2 。 call/2 的函数签名和上面的函数Plug是一样的第一个参数是 %Plug.conn{} 由Phoenix自动传入第二个参数是 init/1 函数的返回值也是由Phoenix自动传入。 init/1 入参的传递方式和上面的函数Plug的第二个参数的传递方式是一样的稍后会介绍。举个例子
defmodule HelloWeb.Plugs.ModulePlug do import Plug.Conndef init(default), do: default def call(conn, _default) do # do somethingconnend
endplug 的第二个身份是宏有了Plug(连接转换器)之后需要将它应用起来这就是 plug 宏做的事情。它接受一个Plug和一个可选参数(默认为 [] )这个可选参数正是函数Plug的第二个参数也是模块Plug的 init/1 函数的参数。例如我们可以像下面这样使用上面的两个Plug
plug :func_plug
plug HelloWeb.Plugs.ModulePlug, your params当然你也可以写成带括号的形式它们仅仅是语法上的区别
plug(:func_plug)
plug(HelloWeb.Plugs.ModulePlug, your params)我们在许多文件里面都能看到 plug 的身影比如 lib/hello_web/endpoint.ex lib/hello_web/router.ex 等。因为无论是endpointrouter还是controller它们本质上都是Plug。
Endpoint
Endpoint是整个后端服务的入口对应着 lib/hello_web/endpoint.ex 文件。一个endpoint会做为一个opt应用启动phoenix本质上还是一个elixir应用在 lib/hello/application.ex 文件的 start 函数中可以看到endpoint是做为opt启动的。
def start(_type, _args) dochildren [...# Start the Endpoint (http/https)HelloWeb.Endpoint...]# See https://hexdocs.pm/elixir/Supervisor.html# for other strategies and supported optionsopts [strategy: :one_for_one, name: Hello.Supervisor]Supervisor.start_link(children, opts)
endEndpoint做为入口除了做为opt应用它里面还“插入”了许多公共的Plug其中最重要的是下面这行代码
plug HelloWeb.Router通过这行代码我们将Router(路由器)带了进来它会负责请求的分发也就是解决web框架的那个最核心的问题。
Router
Router就是我们熟知的路由器它本质上也是一个Plug对应着 lib/hello_web/router.ex 文件。让我们来看下Phoenix为我们生成的路由器代码 scope /, HelloWeb dopipe_through :browserget /, PageController, :homeend先来看 get /, PageController, :home 这行代码它注册了一个根路由 / 方法是GET这也是Phoenix欢迎页的路由。 PageController 是我们的控制器 :home 是此路由对应的处理函数在Phoenix中称为Action。
除了 get Phoenix也为其他HTTP方法定义了对应的宏如 head post put 等他们都定义在 Phoenix.Router 模块下。
虽然示例中路由被放到了Scope内但这并不是必须的。
Scope
在Router中路由代码被放到了 scope 代码块内。Scope其实就是组路由它可以对具有相同前缀的路由进行分组并且可以对组内路由设置公共中间件。比如在Router示例代码中的 scope 下面还有这么一行代码 pipe_through :browser 。
pipe_through 是应用中间件的宏而 :browser 就是中间件。不过在Phoenix中它们被称为Pipeline。
Pipeline
在Phoenix中中间件被称为Pipeline由 pipeline 宏来定义。借鉴图形学的概念这里其实把Pipeline翻译为管线更加合适但是从概念理解上它等同于中间件。
Pipeline本质上就是一个Plug的列表如下图所示 如果整个web层是一串大糖葫芦那么pipeline就是一串小糖葫芦。 :broswer 管线的定义如下
pipeline :browser doplug :accepts, [html]plug :fetch_sessionplug :fetch_live_flashplug :put_root_layout, html: {HelloWeb.Layouts, :root}plug :protect_from_forgeryplug :put_secure_browser_headers
endPipeline内是通过 plug 宏插入的一系列Plug是不是很像串糖葫芦。连接在真正交给Controller之前会首先依次经过Pipeline中的Plug的处理。注意 plug :put_root_layout, html: {HelloWeb.Layouts, :root} 这行代码它会像浏览器写回网页的公共部分如布局。这样在Controller中就只需要返回具体的HTML内容了。
除了 :browser Phoenix还生成了一个 :api Pipeline当我们编写API接口时可以使用它。
pipeline :api doplug :accepts, [json]
endController
Controller就是我们熟知的控制器了不出意外它本质上也是一个Plug对应的代码在 lib/hello_web/controllers 目录下我们看到的欢迎页就是 page_controller.ex 渲染出来的源码如下
defmodule HelloWeb.PageController douse HelloWeb, :controllerdef home(conn, _params) do# The home page is often custom made,# so skip the default app layout.render(conn, :home, layout: false)end
end欢迎页的Controller非常简单只有一个 home/2 函数用来渲染页面。在Phoenix中它也称为Action。
虽然Controller和Router看起来都不太像我们前面介绍的Plug但它们的确是Plug这就是Elixir宏的魔力。
Action
HTTP请求方法方法除了有名词属性还有动词属性。比如针对某个路径的一次GET请求这个动作就称为Action。在Controller中我们也将用来处理连接请求的函数称为Action。
一个函数要作为Action必须接受两个参数第一个是表示连接的 %Plug.conn{} 结构体第二个是记录着HTTP请求参数的map。在Action中不应该有过多的业务逻辑只保留web相关的逻辑和渲染相关的代码保持Controller层尽量扁平。
在示例中我们通过 render(conn, :home, layout: false) 来渲染欢迎页。 render 函数是 Phoenix.Controller 模块提供的它有三个参数。第一个是HTTP连接也就是 %Plug.conn{} 结构体第二个参数是HTTP模版可以是二进制的模版数据也可以是一个返回模版的函数第三个参数是渲染模版的参数可以是关键字(Keyword)也可以是map。
注意 render 的第二个参数 :home 这是一个返回HTML模板的函数在Phoenix中被称为Component。
Component
Component是一个返回HTML模版的函数当然它也需要接受一个map或keyword参数。我们可以粗浅的理解Component就是HTML模板。它对应的是lib/hello_web/controller/page_html.ex 文件。
前面我们看到渲染欢迎页的Component是 :home 函数但是当我们打开 page_html.ex 后却怎么也找不到这个函数。这是怎么回事呢
我们先来看下Controller和Component的命名Controller文件叫 page_controller.ex Component文件名叫 page_html.ex 模块名是 HelloWeb.PageHTML 。这些名称可都不是随便起的注意看它们的规律都是page开头加一个有意义的后缀page其实无所谓只要相同就行但后缀是有讲究的。我们在 render 函数中直接引用了 :home 函数并没有指定模块名Phoenix能找到它就是因为这些命名规约。
我们还是没有找到 :home 函数只有这样一行代码 embed_templates page_html/* 。而在controllers目录下的确有page_html这么一个目录里面有一个名为 home.html.heex 的文件home难道说它们之间也有着某种神秘的联系
没错 home.html.heex 文件会预编译为 page_html.ex 里面一个名为 home 的函数。Phoenix使用的是HEEx(HTMLEEx)模板语言EEx是一个Elixir表达式求值的库。HEEx模板文件以 .heex 做为扩展名所以 home.html.heex 的三个部分的含义分别是Component(函数)名称模板类型HEEx扩展名。
对于比较长的模板建议使用这种独立文件的形式而对于一些简短的模板则可以使用函数的形式例如
def home(_assigns) do ~HHello World!
end 你会发现在 lib/hello_web 目录下也有一个独立的 components 目录它里面存放的也是Component不过是网页公共部分如布局等相关的模板。
一次请求
根据前面对概念的梳理我们也能大致看到一条请求在Phoenix中处理的脉络。现在我们再次对一个HTTP请求的处理流程做一个完整的回顾与总结。
请求首先到达Endpoint位于 lib/hello_web/endpoint.ex 在这里有许多Plug会对请求做第一轮的处理。而在这众多的Plug之中Router也是其中之一在Endpoint的最后请求被交给了Router。
Router位于 lib/hello_web/router.ex 它主要做了两件事分组分发与中间件。请求在这里先经过Pipeline处理然后交由对应的Controller。
Controller位于 lib/hello_web/controllers 目录下新项目只有 page_controller.ex 这一个Controller其中定义了Action它们是请求处理的最后一环。在Action中会调用业务逻辑和Component将数据与视图结合形成最终的响应发送回客户端。
以上就是一次请求处理的流程没有看错就是这么的简单Endpoint→Router→Controller→Action。我们暂时省略了代码上的一些细节如果你非常熟悉Elixir的话结合hexdocs中的文档应该不难理解这些代码。此外在RouterController等里面使用的 use 宏对应的源码都在 lib/hello_web/world_web.ex 文件中。
整个请求的过程应该不难理解你可以试着修改模板或者打印一些日志看看页面的变化和控制台输出日志使用的是Erlang的 :logger 模块。
本章完下期见。
