总结

1.基础知识面试题，面试宝典上都有，每天都要背
2.基础增强中的集合、线程（线程关键字、线程池）、io、网络编程 重点背（原理）
3.mysql,事务特性、索引原理、索引优化、索引失效、每天写最少5个sql语句
4.前端VUE了解会写简单的内容、必须能看懂（部分公司会让写前端）
5.web阶段servlet生命周期、过滤器、拦截器、重定向、转发、域对象
6、框架阶段，三大框架，springmvc执行流程问的最多，过滤器与拦截器，文件插件，springbean生命周期
IOC的执行流程，AOP原理，spring事务机制，事务传递
7、springboot的启动流程，start原理
8、cloud各个组件，必须会用、熟练，（能扩展原理最好）
9、ES、Redis、MQ、xxl、zk、dubbo
10、项目业务（下面是面试问题）
你觉得除了这些crud的项目，你印象最深刻的一个项目是什么？
聊了下项目、你负责xxx项目的模块，整体业务可以介绍下吗
项目整体流程，你负责什么，遇到最大的问题是什么，怎么解决的？对你的收获是什么？
用户登录注册逻辑如何实现，hash加密和md5加密有何区别
团队人员的组成，开发规模有多大，平时是如何迭代开发一个需求的（从产品经理到最终上线的流程）
你在项目里面得到了学习到了什么，得到了哪些技术提升
简单介绍介绍一下你在上家公司做过的项目、项目的主要流程、你所负责的模块、你在项目担任的职责

entity层
A：entity就是属性类，通常定义在model层里面，相当于MVC的M层，属于数据模型层
B：一般得实体类对应一个数据表，其中的属性定义数据表中的字段，实体类的字段数量 >= 数据库表中需要操作的字段数量
dao层
A：dao层叫做数据访问层，全称为data access object(数据访问对象)，属于一种比较底层基础得操作，具体到对某个表得增删改查，换句话说，某个dao一定是和数据库中的某一张表一一对应的，而且其中也只是封装了增删改查得方法
service层
A：service层即为业务逻辑层，可以理解为对一个或者多个dao进行得再次封装，主要是针对具体的问题的操作，把一些数据层的操作进行组合，间接与数据库打交道（提供操作数据库的方法）。要做这一层的话，要先设计接口，再实现类。
controller层
A：负责请求转发，接收页面过来的参数，传给service处理，接到返回值，并再次传给页面
mapper层
A：数据存储对象，相当于DAO层，mapper层直接与数据库打交道（执行SQL语句），接口提供给service层。

Java：简述Java开发中的实体类
一、实体类
百度百科中对于 实体类 的定义为：实体类的主要职责是存储和管理系统内部的信息，它也可以有行为，甚至很复杂的行为，但这些行为必须与它所代表的实体对象密切相关。

根据以上定义，我们可以了解到，实体类有两方面内容，存储数据和执行数据本身相关的操作。这两方面内容对应到实现上，最简单的实体类是 POJO（Plain Ordinary Java Object） 类，含有属性及属性对应的set和get方法，实体类常见的方法还有用于输出自身数据的toString方法。

二、领域模型中的实体类
领域模型中的实体类分为四种类型：VO、DTO、DO、PO。各种实体类用于不同业务层次间的交互，并会在层次内实现实体类之间的转化。

VO、DTO、DO、PO的解释如下：

VO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。

DTO（Data Transfer Object）：数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但本文，泛指用于展示层与服务层之间的数据传输对象。

DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。

PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。

业务分层为：视图层（View+Action），服务层（Service），持久层（DAO）

相应各层间实体的传递如下图：

项目中我们并没有严格遵循这种传递关系，但这种和业务层次的关联对我们理解各实体类的作用是有帮助的。

项目模型：

用户发出请求（可能是填写表单），表单的数据在展示层被匹配为VO。
展示层把VO转换为服务层对应方法所要求的DTO，传送给服务层。
服务层首先根据DTO的数据构造（或重建）一个DO，调用DO的业务方法完成具体业务。
服务层把DO转换为持久层对应的PO（可以使用ORM工具，也可以不用），调用持久层的持久化方法，把PO传递给它，完成持久化操作。
对于一个逆向操作，如读取数据，也是用类似的方式转换和传递，略。
三、项目中的实体类
项目中常见的实体类有VO，DO和DTO，命名规则也常是以相应字符串结尾，如 * VO.Java。

项目中实体类出现的业务层次也没有这么严格，例如我们可以在视图层就组装一个DO，也可以将一个VO从持久层传出来，所以与业务分层相关联的划分方法显得有些冗余。

从项目代码中抽象出的理解是：VO对应于页面上需要显示的数据，DO对应于数据库中存储的数据，DTO对应于除二者之外需要进行传递的数据。

概括

DTO:前端给后端传递的数据
VO:后端给前端传递的数据
DO:数据库表结构
PO:数据库表结构到JAVA的映射类
一般我们使用Mybatis建的类为PO,控制器接受到前端发来的参数为DTO,给前端发送的安全的数据为VO。如果数据类不做映射处理关系时PO=DO

缩写的含义

PO 是 Persistant Object 的缩写，用于表示数据库中的一条记录映射成的 java 对象。PO 仅仅用于表示数据，没有任何数据操作。通常遵守 Java Bean 的规范，拥有 getter/setter 方法。

DAO 是 Data Access Object 的缩写，用于表示一个数据访问对象。使用 DAO 访问数据库，包括插入、更新、删除、查询等操作，与 PO 一起使用。DAO 一般在持久层，完全封装数据库操作，对外暴露的方法使得上层应用不需要关注数据库相关的任何信息。

VO 是 Value Object 的缩写，用于表示一个与前端进行交互的 java 对象。有的朋友也许有疑问，这里可不可以使用 PO 传递数据？实际上，这里的 VO 只包含前端需要展示的数据即可，对于前端不需要的数据，比如数据创建和修改的时间等字段，出于减少传输数据量大小和保护数据库结构不外泄的目的，不应该在 VO 中体现出来。通常遵守 Java Bean 的规范，拥有 getter/setter 方法。

DTO 是 Data Transfer Object 的缩写，用于表示一个数据传输对象。DTO 通常用于不同服务或服务不同分层之间的数据传输。DTO 与 VO 概念相似，并且通常情况下字段也基本一致。但 DTO 与 VO 又有一些不同，这个不同主要是设计理念上的，比如 API 服务需要使用的 DTO 就可能与 VO 存在差异。通常遵守 Java Bean 的规范，拥有 getter/setter 方法。

BO 是 Business Object 的缩写，用于表示一个业务对象。BO 包括了业务逻辑，常常封装了对 DAO、RPC 等的调用，可以进行 PO 与 VO/DTO 之间的转换。BO 通常位于业务层，要区别于直接对外提供服务的服务层：BO 提供了基本业务单元的基本业务操作，在设计上属于被服务层业务流程调用的对象，一个业务流程可能需要调用多个 BO 来完成。

POJO 是 Plain Ordinary Java Object 的缩写，表示一个简单 java 对象。上面说的 PO、VO、DTO 都是典型的 POJO。而 DAO、BO 一般都不是 POJO，只提供一些调用方法。

应用

不同类型的对象在架构设计中用于不同的用途，如下的分层架构表示了各个 POJO 的用途。为什么要在分层架构中，定义这些 POJO 对象呢？主要是为了确保各个分层能够很好地封装自己的服务，有效地控制信息的传播。

试想一下，如果没有 VO 和 PO 的区别，那么数据库表结构的所有字段就一览无余地展示到了前端，给后台安全带来很大的隐患，并且无法在网络传输中剥离冗余信息提高了用户的带宽成本。

实例

以一个实例来探讨下 POJO 的使用。假设我们有一个面试系统，数据库中存储了很多面试题，通过 web 和 API 提供服务。可能会做如下的设计：
数据表：表中的面试题包括编号、题目、选项、答案、创建时间、修改时间；
PO：包括题目、选项、答案、创建时间、修改时间；
VO：题目、选项、答案、上一题URL、下一题URL；
DTO：编号、题目、选项、答案、上一题编号、下一题编号；
DAO：数据库增删改查方法；
BO：业务基本操作。
可以看到，进行 POJO 划分后，我们得到了一个设计良好的架构，各层数据对象的修改完全可以控制在有限的范围内。

SSM 是 Spring + SpringMVC + Mybatis集成的框架。

一、entity层
同类： model层 = entity层 = domain层
作用： 用于存放我们的实体类，与数据库中的属性值基本保持一致。

二、mapper层
同类： mapper层 = dao层
作用： 对数据库进行数据持久化操作，他的方法语句是直接针对数据库操作的

三、service层
同类： 只有一个 service层
作用： service层 是针对 controller层的 controller，也就是针对我们使用者。service的 impl 是把mapper和service进行整合的文件。

四、controller层
同类： controller层 = web 层
作用： 控制器，导入service层，因为service中的方法是我们使用到的，controller通过接收前端传过来的参数进行业务操作，再将处理结果返回到前端。

在看一些实际的项目的源码的时候，我们会发现POJO、VO、DTO、PO、Entity、domain的区别,那它们分别是什么呢，与我们学习Java时遇到的POJO有什么不同呢。下面就来简单的谈谈一下我对它们的一个理解。
1、POJO（Plain Ordinary Java Object）：即无规则简单Java对象，就是一个我们最常见的普通Java对象，这个概念是被大家叫出来的，它具有一些属性，然后提供对应的getter和setter。即不与数据库打交道的简单对象。
一个中间对象，可以转化为VO、DTO、PO

2、VO（View Object）：视图对象【表示层对象】，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。即和html、jsp等页面属性对应的java对象。
对应页面显示的数据对象，可以和表对应，也可以不对应。一般在Controller层使用

3、DTO（Data Transfer Object）：数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于展示层与服务层之间的数据传输对象。即提取数据库中所需要的的属性减少不需要的属性来提高传输速度、流量。
传递数据。如PO有100个属性，页面VO只显示10个，那么DTO就也传输10个。一般在Service层使用

4.、Entity ：entity里的每一个字段，与数据库相对应。
实体，和PO的功能类似，和数据表一一对应，一个实体一张表

5、PO（Persistent Object持久化对象）持久化对象，它跟数据表形成一一对应的映射关系。
一般在Dao层使用

6、domain：即领域模型 银行 保险 电商 物流 医疗 DDD 领域驱动设计
需要和相关领域的专家讨论得出。


domain entity model之间的区别
先用三句话来简单描述一下他们各自的特点：

名称

特点

entity

字段必须和数据库字段一样

model

前端需要什么我们就给什么

domain

比较少用，代表一个对象模块

1.entity实体

entity就是实体的意思，也是我们最常用到的。entity包中的类是必须和数据库相对应的。比如说：数据库有个user表，字段有long类型的id，string类型的姓名，那么entity中的user类也必须是含有这两个字段的，且类型必须一致。不能数据库存的是long类型，user类里的属性是string类型。

这样做的好处是保持实体类和数据库保持一致，另外，当用到hibernate或mybatie框架来操作数据库的时候，操作这个实体类就行，写sql之前不需要再做数据格式处理。

2.model模型

model大家不陌生，都知道是模型的意思，当用model当包名的时候，一般里面存的是实体类的模型，一般是用来给前端用的。比如：前端页面需要显示一个user信息，user包含姓名，性别，年龄，这些信息存在数据库的时候，姓名直接存姓名，但是性别和年龄一般会用数据字典的编号存到数据库，比如：1代表男，2代表女，数据库存的就是1或2，如果用entity的话，把1、2给前端，前端就不知道是什么玩意，就算前端知道1代表男，2代表女，写了一个js判断数据处理，后来数据库变动了，1代表女，2代表男，前端的js又需要重新写，很显然这样不利于维护。所以就需要model来解决，后台从数据库取了数据转化为前端需要的数据直接传给前端，前端就不需要对数据来处理，直接显示就行了。还有一种情况，数据库里面的user表字段有十个，包含姓名，qq，生辰八字乱七八糟的等等，但是前台页面只需要显示姓名，如果把entity全部传给前台，无疑传了很多没用的数据。这时候model就很好的解决了这个问题，前台需要什么数据，model就包含什么数据就行了。

3.domain域

domain这个包在国外很多大型项目经常用到，字面意思是域的意思。它的范围就有点广了，比如一个商城的项目，商城主要的模块就是用户，订单，商品三大模块，那么这三块数据就可以叫做三个域，domain包里就是存的就是这些数据，表面上这个包和entity和model包里存的数据没什么区别，其实差别还是挺大的，特别是一些大型的项目。比如一个招聘网站的项目，最重要的对象就是简历了，那么简历是怎么存到数据库的呢，不可能用一张表就能存的，因为简历包含基本信息和工作经验，项目经验，学习经验等。基本信息可以存在简历表，但是涉及到多条的就不行，因为没人知道有多少条工作经验，项目经验，所以必须要单独建工作经验表和项目经验表关联到简历基本信息表。但是前台页面是不关心这些的，前台需要的数据就是一个简历所有信息，这时就可以用到domain来处理，domain里面的类就是一个简历对象，包含了简历基本信息以及list的工作经验，项目经验等。这样前端只需要获取一个对象就行了，不需要同时即要获取基本信息，还要从基本信息里面获取工作经验关联的简历编号，然后再去获取对应的工作经验了。

当然，如果用model的话也是可以达到domain的效果的。这个完全是看个人喜好和项目的整体架构，因为创建不同的package的作用本来也就是想把项目分成不同的层，便于管理和维护。如果你乐意，你可以创建entity包，然后在里面存图片，创建images文件夹，里面存js。你自己能看懂就行，前提是如果是团队开发的话能保证别人不打你。这个和语言一个道理，你在200年前和英国人说：private void set(int age),人家说：滚犊子；现在你这样说，人家就知道是java语言了。能被人们通用的才叫语言，你说的别人听不懂那只能算是鸟语。所以开发的时候，建类建包的命名规则规范性还是很重要的。