web开发

web项目

前端请求的生命周期

用户在web界面上点击了一个按钮，就由前端发起了一个请求，那这个请求的生命周期是什么样的？

通常情况，后端的工作是解析前端的数据、处理对应的业务逻辑，返回操作结果

这里，离不开三层概念：

• API层：解决来自前端的请求数据，转化成go的数据结构

• service层：包含业务逻辑，是这个请求具体要做的事情

• Dao层：数据持久化，也就是更新到数据库，保证不丢失

不同的框架有不同的命名方式，但我个人建议只关注这三层即可

第一层：API层

通常来说，API层只做三件事

1. 根据路由规则，调用具体的处理函数，常见的RESTful就是有 URL + Method 作为路由规则；

2. 解析文本或二进制数据到GO结构体，常见的就是json反序列化；

3. 调用下一层Service的函数；

在开发的过程中，对于API层需要重点关注这几点：

• 可读性：可以快速地根据命名了解功能，如RESTful

• 高度复用：如引入各种中间件，比如防止panic、用户认证、日志打印等

• 尽量薄：不做或少做逻辑处理，复杂处理都丢到service层

• 文档化：将接口相关的参数通过文档给到前端，尽量做到自动化或半自动化

API层是程序的入口和出口，能很好地追踪到数据到前后变化情况。一个优秀的API层实现，不仅能少写很多重复性的代码，也能大幅度降低排查问题的时间。

第二层：Service层

Service层可以理解为服务层，是整个项目中最复杂、也是代码比重是最多的，它是一个项目最核心的业务价值所在。

Service是最灵活，也是最考验设计能力的，虽说没有一套固定的模式，但还是会有一定的套路。

我分享下个人的三个见解：

1. 单元测试覆盖率要尽量高，这是一个高频迭代与重构的模块，也是最容易出现问题的部分；

2. 深入实践 面向对象和DDD，最锻炼工程师抽象、解耦等能力的模块；

3. 选择合适的 设计模式 可大幅度提升研发效率；

service层是和业务一起成长的，前期没必要过度设计，重点应该放在单元测试上，适当选用一些库来提升效率，如开源的stretchr/testfy，内部的reflect等。

第三层：Dao层

Dao层常被理解为数据持久层，但我们可以进一步延伸：将RPC调用也当做Dao层（不妨认为将数据持久化到另外一个服务）

关于Dao层，认为部分实践比较通用：

1. 选用官方或社区高频使用的库，避免后期出现功能缺失或性能瓶颈的问题

2. 灵活性比易用性更重要，通过一层潜封装，往往能更适配项目，达到更棒的易用性。

3. 关注数据库的原理，而不是ORM工具的实现方式，数据库的原理是长期的积累，对技术选型和排查故障很用帮助。

串联三层

到这里，对三层架构有了一个初步的了解，可以总结为两边薄(API, Dao)、中间厚(Service)

这里的实践需要不断的打磨，比如说：

• API和Dao会随着个人编程能力的提升，不断地总结出更好的编程实践；

• 做性能优化时，优先考虑Dao，其次考虑API，这两部分的提效是最明显的；

• 排查问题时，先分析API的出入口，再分析Dao的出入口，实在解决不了再看service(此时问题已经是比较严重了业务问题了)。

到最后，相信大家对这三层认知会进一步的提升：

• API：服务对外的门面，通过一个接口定义就能了解实现原理；

• Service：复杂的业务逻辑，非该服务的核心不需要关注，而核心成员需重点维护；

• Dao：无论是调用ORM还是SDK，都视为一种工具集，是一个技术人员沉淀能力的重点。

CRUD程序员

• API层：遵循RESTful的原则，提高可读性

  • 将操作(CRUD)对应到HTTP的Method

  • 将资源对象对应到http的UR

• Service层：

  • 对于只是简单的修改，Service不用做复杂处理，透传到Dao层即可

  • 如果涉及到多个表的修改，进行事务处理

  • 在Dao层出现错误时，适当封装错误信息，提高可读性

• Dao层：

  • 选择并熟练运用ORM，快速实现基本的CRUD

  • 对复杂的ORM进行一层浅封装，方便Service层的调用

结束语

Web项目是我们平时最常见的项目类型，也是很多面试考点的基石

建议大家从分层入手，明确各层职责，关注API与Dao层的提效工作，做好Service层的质量保证

标签：API,web,Service,service,Dao,开发,ORM,三层
来源： https://www.cnblogs.com/yaoqingzhuan/p/15862849.html