Java三层框架的解析

记得开心一点嘛 2024-07-13 16:35:01 阅读 91

引言:欢迎各位点击收看本篇博客,在历经很多的艰辛,我也是成功由小白浅浅进入了入门行列,也是收货到很多的知识,每次看黑马的JavaWeb课程视频,才使一个小菜鸡见识到了Java前后端是如何进行交互访问的,话不多说,进入正题。


目录

一.三层框架:

二.前后端交互过程:

 三.如何进行接口测试:

 四.三层架构的设计模式:

五.正式入门三层框架:

1.首先要写controller层:

2.service层的写法:

3.dao层的写法:


 

一.三层框架:

我们在进行程序开发时,应该遵守单一职责原则,意思就是尽可能让每个接口、类、方法的职责更单一,如果我们将整个后端代码放在一个包一个类中,不仅仅是代码的可阅读性差,而且代码冗杂,耦合度很高。

1. controller:控制层,负责接受前端发送来的请求,对请求进行处理,并相应数据。

2. service:业务逻辑层,处理具体实现的业务逻辑。

3. dao:数据访问层(持久层),负责数据访问操作,包括数据的增删改查。

二.前后端交互过程:

首先通过浏览器发起请求,经过DispatcherServlet(称为核心控制器或者前端控制器)将请求信息封装到HttpServletRequest这个对象内,然后再将这个请求转给后面的每个Controller程序,由Controller程序对其进行处理(Controller程序通过调用Service程序,然后再Service程序中调用Mapper程序,最后Mapper程序处理完返回给Service然后再返回给Controller),随后Controller程序将处理完的响应信息返回给DispatcherServlet的HttpServletResponse对象中,然后DispatcherServlet再给浏览器响应数据。这也就是BS架构,浏览器/服务器架构模式。

 三.如何进行接口测试:

我们在写完后端程序肯定需要进行测试来判断代码的准确性,但是如果我们没有前端页面进行测试,我们如何进行接口测试呢?这个时候就需要使用Postman或者Apifox来进行接口测试。

 四.三层架构的设计模式:

根据第一与第二点,我们初步理解了三层框架的进行顺序,那么三层框架该是什么样的创建形式呢?

根据上图,我们可以看到这个是基于Springboot来开发的,在java.com.itheima包下创建了四个包以及运行类,而这四个包分别装有其分别对应的类与接口。 

我们都知道接口是Java程序对类定义其规则,所以一般我们在开发的时候会现在接口内写入想要实现的方法名,然后再实现类中写出实现方法。 

五.正式入门三层框架:

在学习三层框架,我们都知道三层框架有controller,service,dao三层,所以咱们在写接口的过程要按照其实现顺序依次写入。

我们先在pom.xml导入依赖以及在application.properties中写入MySQL的驱动以及配置文件的相关信息,,然后在tlias数据库下创建一个Dept部门类和一个Emp员工类。

pom.xml文件导入依赖:1.Springboot 2.MySQL 3.Lombok 4.pagehelper(分页插件)

application.properties配置文件写法:

<code>spring.application.name=tlias

spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

spring.datasource.url=jdbc:mysql://localhost:3306/tlias

spring.datasource.username=root

spring.datasource.password=lxs15241690479

mybatis.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutImpl

mybatis.configuration.map-underscore-to-camel-case=true

1.首先要写controller层:

我们在写controller层之前要知道SpringBoot对注解的使用:

1. @ResponseBody:放在开头代表每个方法的返回值都会作为响应数据,如果是对象或者集合会先转为json格式然后再来响应。

2. @Controller:控制器组件

3. @RestController:主要由ResponseBody+Controller两个注解组成,也就会有这两个注解的作用。

4. @RequestMapping("url"):一个用来处理请求地址映射的注解,可用于映射一个请求或一个方法,可以用在类或方法上。

5. @***Mapping:这***是代表其有很多的样式,也就是要填入请求方式,如:Get,Post,Delete等。跟@RequestMapping差不多,但是使用这个注解就要跟随该注解前的请求方式才能够请求。

6. @RequestParam:

 用于将指定的请求参数赋值给方法中的形参。

有三个属性:

(1)value:请求参数名(必须配置)

(2)required:是否必需,默认为 true,即 请求中必须包含该参数,如果没有包含,将会抛出异常(可选配置)

(3)defaultValue:设置默认值,如果设置了该值,required 将自动设为 false,无论你是否配置了required,配置了什么值,都是 false(可选配置)

7.@PathVariable:

    @PathVariable是Rest风格衍生出的占位符,只支持一个属性value,类型是为String,代表绑定的属性名称。默认不传递时,绑定为同名的形参。 用来便捷地提取URL中的动态参数。应用时,在@RequestMapping请求路径中,将需要传递的参数用花括号{}括起来,然后,通过@PathVariable("参数名称")获取URL中对应的参数值。如果@PathVariable标明参数名称,则参数名称必须和URL中参数名称一致。

8. @Autowired:自动注入,上一篇Mybatis讲过,这里不细说。有需要了解请跳转:

Mybatis不明白?就这一篇带你轻松入门_mapper 新建一张表在哪里配置-CSDN博客

下面将@RequestBody放在前面的目的是为了简化写法,因为下面的@***Mapping()内都需要加上某url所以我们可以将/depts提前来简化写法,所以下面那个@GetMapping后面不是没有接口地址而是因为简化写法省略。

@Slf4j

@RequestMapping("/depts")

@RestController

public class DeptController {

@Autowired

private DeptService deptService;

@GetMapping

public Result list(){

log.info("查询全部部门数据");

List<Dept> deptList = deptService.list();

return Result.success(deptList);

}

@DeleteMapping("/{id}") //动态接收数据

public Result delete(@PathVariable Integer id){

log.info("根据id删除部门:{}" + id);

deptService.delete(id);

return Result.success();

}

@PostMapping

public Result add(@RequestBody Dept dept){//json格式使用实体类接受

log.info("新增部门:{}" , dept);

deptService.add(dept);

return Result.success();

}

}

有时我们为了接受大量的数据也会定义一个实体类然后使用@RequestBody注解进行接收。

然后我们在这些Controller程序的方法看见其内部紧跟随调用其对应的Service方法来操作所接收的数据,随后return返回一个Result类success方法。下面的是Result类->

@Data

@NoArgsConstructor

@AllArgsConstructor

public class Result {

private Integer code;//响应码,1 代表成功; 0 代表失败

private String msg; //响应信息 描述字符串

private Object data; //返回的数据

//增删改 成功响应

public static Result success(){

return new Result(1,"success",null);

}

//查询 成功响应

public static Result success(Object data){

return new Result(1,"success",data);

}

//失败响应

public static Result error(String msg){

return new Result(0,msg,null);

}

}

上面的三个注解不懂的可以看我上篇文章,里面详细写出了Mybatis的相关内容。

 既然我们会调用service进行操作,所以接下来我们就进行service的操作。

2.service层的写法:

@Service:Spring Framework 中的一种注解,它标识了这个类是一个业务逻辑层的服务 Bean。这意味着当 Spring 应用启动时,该 Bean 会被自动创建并加入到 Spring 应用上下文中。简而言之,@Service 注解是一种用于标记服务层 Bean 的注解,是在 Spring Boot 应用中实现业务逻辑复用的重要方法之一。

业务逻辑层,处理具体实现的业务逻辑(处理数据),我们需要再其内部加上很多的操作方法所以先写接口后写类。

接口内写入规则:

public interface DeptService {

List<Dept> list();

void delete(Integer id);

void add(Dept dept);

}

然后创建其实体类:

@Service

public class DeptServiceImpl implements DeptService {

@Autowired

private DeptMapper deptMapper;

@Override

public List<Dept> list() {

return deptMapper.list();

}

@Override

public void delete(Integer id) {

deptMapper.deleteById(id);

}

@Override

public void add(Dept dept) {

dept.setCreateTime(LocalDateTime.now());

dept.setUpdateTime(LocalDateTime.now());

deptMapper.insert(dept);

}

}

我们发现这层的方法体内代码非常的少,是不是可以直接与Mapper合并一层?

nonono,绝对不行的,这样会破坏原本三层架构的完整与独立性,而且三层架构低耦合,并且其注解的独立使用也无法让你变成两层架构,其实这个只是当前的代码不用写很多代码,如果咱们以后写大程序就可以看出service层的重要,每一层都是不可缺少的。

3.dao层的写法:

对于dao层,主要通过注解或者xml来操作数据,这里需要用到Mybatis的基础,详情请看下面链接,有我码一万四千多字的博客:Mybatis不明白?就这一篇带你轻松入门_mapper 新建一张表在哪里配置-CSDN博客

@Mapper

public interface DeptMapper {

@Select("select * from dept")

List<Dept> list();

@Delete("delete from dept where id = #{id}")

void deleteById(Integer id);

@Insert("insert into dept(name, create_time, update_time) value (#{name} , #{createTime} , #{updateTime})")

void insert(Dept dept);

}

随后我们点击执行类运行程序,然后使用Postman或者Apifox进行测试接口,同时也要注意请求方式的使用以及路径的正确书写,我们一般写成localhost:8080/depts/......,剩下的就由你来完成了。


最后,我们可以看出三层框架很简单,但是内部用到了很多知识点,这就需要咱们多学多练多观察,别忘了点个关注,多多支持,记得三连哈,有问题欢迎在评论区里留言。



声明

本文内容仅代表作者观点,或转载于其他网站,本站不以此文作为商业用途
如有涉及侵权,请联系本站进行删除
转载本站原创文章,请注明来源及作者。