重构的定义：重构是对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本

　　从定义里我们可以看出，重构是对代码和架构的一种修改，旨在提高代码的效率和可读性，来达到降低修改成本的目的。而重构对于用户体验来说，就像定义中说到的，只能对可观察行为作出很小的变化，甚至不造成变化。

关于同事些代码经常会把DAO注入到表现层Controller里面使用，我一直很反感这样的做法，奈何找不出可以反驳这些老员工的理由，确实才疏学浅了。

认真想想

例如，一般情况，我们会在Service层定义了一个接口，并实现了这个接口，接着我们在Controller里面调用这个接口。若是这一段逻辑直接被写在Controller A里，而不定义成接口，那么其他的Controller B将无法调用到这个接口的业务逻辑，只能将A中的业务逻辑代码拷贝一份，放到B里，并将B调用到的DAO注入进来，这样造成了不必要的代码冗余。为将来修改这段业务逻辑造成了很大的隐患。

例如，DAO中提供了save方法，Service中也定义了save方法，其代码为return daoInstance.save()。Controller中再定义save方法，其代码为业务逻辑1;serviceInstance.save();业务逻辑2;return;

对于这样的代码，我们是否应该直接调用dao.save()而不通过service来执行save操作呢，这里就要明确三层架构的意义了

又或者Controller里应该做这样的事，把表单参数dataModel封装成一个Map或一个对象，传递给service，并在接口实现类中进行业务逻辑的编写，这样也符合了事物规范

我应该好好思考一下这个项目提供的架构到底有什么缺陷，并且我们应该怎么来分层写代码

对于在Controller里面写dao.excuteSqlByJDBC()我坚信是大错特错的行为。你在Controller里执行SQL语句，完全偏离了事务的概念，如果执行出错，业务逻辑讲不能被rollback。

另一种情况是同事喜欢在Controller里面写SQL查询，查询本身不需要事务支持，也应该没有回滚一说吧，无非就是查的出，或是报错查不出的情况，不会影响到系统的实际数据。这样的行为到底是否可取呢？我认为他们确实觉得去service里定义接口，再定义实现类执行SQL语句去查询特别麻烦，所以干脆将DAO注入到Controller里面直接使用。虽然会导致一些代码复用性的隐患，但如果这段查询代码本就不需要复用呢？如何给这样的操作提供便利，我想了很多。

我想既然是执行SQL，那无所谓哪个实体，自当在架构中定义一个commonDAO来执行，有了commonDAO那自然也应该有commonService接口以及对应的实现类的支持。我又想，对于commonService的对象，作为一个工具类，它应该是单例的，必须是静态单例的。commonDAO同样应该是单例的。这样就可以解决在Controller里直接执行SQL的问题了，也省去了复杂的注入操作，更不会出现把DAO注入到Controller里使用的情况