MVC架构设计模式

不使用mvc架构的缺陷

在不使用MVC架构模式的前提下，完成银行账户转账。
分析这个程序存在哪些问题?

1. 缺点1>代码的复用性太差。(代码的重用性太差)

   导致缺点1的原因?

   因为没有进行”职能分工”，没有独立组件的概念，所以没有办法进行代码复用。代码和代码之间的耦合度太高，扩展力太差。

2. 缺点2>耦合度高，导致了代码很难护展。

3. 缺点3>操作数据库的代码和业务逻辑混杂在一起，很容易出错。编写代码的时候很容易出错，无法专注业务逻辑的编写。

分析以下AccountTransferServlet他都负责了什么?

1. 负责了数据接收

2. 负责了核心的业务处理

3. 负责了数据库表中数据的CRUD操作 (Create【增】 Retrieve【査】 Update【改】 Delete【删】)

4. 负责了页面的数据展示

公司中一般都有很多员工，每个员工都各司其职，为什么要这样?
保洁阿姨负责打扫卫生
杜老师负责教学大纲的指定
郭老师负责上课
王老师负责学习就业
*我们公司只有一个员工。这个员工负责所有的事情。生病了。–>公司倒闭了。

理论基础

javaEE设计模式之DAO模式

AccountDao是负责Account数据的增删改查的。

1. 什么是DA0 ?
   Data Access 0bject(数据访问对象)
2. DAO实际上是一种设计模式，属于JavaEE的设计模式之一。(不是23种设计模式。)
3. DA0只负责数据库表的CRUD，没有任何业务逻辑在里面。
4. 没有任何业务逻辑，只负责表中数据增删改查的对象，有一个特殊的称谓:DA0对象。
5. 为什么叫做AccountDao呢?
   这是因为这个DA0是专门处理t_act这张表的。
   如果处理t_user表的话，可以叫做:UserDao
   如果处理t_student表的话，可以叫做:StudentDao
6. 一般情况下:一张表会对应一个DA0对象。
7. DA0中的方法名很固定了，一般都是:
   insert
   deleteByXxx
   update
   selectByXxX
   selectAll

/**
* 账户实体类:封装账户信息的。
* 一般是一张表一个。
* @author 老社
* 
* @version 1.0
* 
* @since 1.0
* /
public class Account {
	//一般这种属性不建议设计为基本数据类型，建议使用包装类。防止null带来的问题
	//private long id;
	private Long id;
	private String actno;
	//private double balance;
	private Double balance;
}

像account这种普通简单的对象被称为pojo对象，有的人也会把这种专门封装数据的对象，称为bean对象。有的人也会把这种专门封装数据的对象，称为领域模型对象，domain对象。这些说的都是同一个东西

业务层

service翻译为:业务
AccountService:专门处理Account业务的一个类
在该类中应该编写纯业务代码。(只专注业务。不写别的。不和其他代码混合在一块。)
只希望专注业务，能够将业务完美实现，少量bug.
起名要和业务挂钩

控制层：

// 接收数据
//调用业务方法处理业务(调度Model处理业务)
//展示处理结果(调度View做页面展示)

解决事务问题

在视频代码里，server层开启事务时创建的connection对象和dao层crud创建的connection对象不是同一个，所以并没有成功开启事务管理，这时候通过创建一个map，key保存的是线程，value保存的是conn对象，这样就可以保证在一个栈里互不影响。比如张三执行这个方法拿到的线程是t1，那么后续执行的方法线程一定是t1，这时候如果有个李四，那他拿到的就会是t2，后面也是一样

静态变量特点:类加载时执行，并且只执行一次。

目前项目仍然存在缺陷:
1>在service层控制了事务，service方法中的事务控制代码看着有点别扭，以后能不能不写????
可以使用动态代理机制解决这个问题。这个自己研究就行了。我不讲了。
2>日前虽然面向接口编程了，但是并没有完全解决对象和对象之间的依赖关系。怎么办?可以使用spring的IoC容器来解决这个问题。
对象的创建我不用管了。
对象和对象之间关系的管理我也不想管了。
都交给spring容器来负责这件事。