学员会诊之03：你那惨不忍睹的三层架构

最近检查作业，虽然我们反复强调三层架构就是：表示层、业务逻辑层、数据访问层，每个层只做自己应该做的事情，但是，部分同学的作业还是不理想啊~~~

你以为的三层架构是这样的：

而实际上你的三层架构是这样的：

如果我们尚不能完全了解把握各个层的边界，那么我们首先仅需要记住下面两句话：

1：除了UI层，任何其它层不要出现System.out；

2：除了DAO层，任何其它层不要出现SQL；

1.除了UI层，任何其它层不要出现System.out

在三层架构的作业中，我们写到：

这句话本来说的是service层应该是和具体的数据存储无关的，但是反过来说，service同时也应该是和具体的页面展示无关的。这是什么意思呢？

先来看赵同学的这个项目结构：

Very清晰，没有任何问题（其实有问题）。但现在让我们打开biz下的一个文件：

可以看到，在Service层的ScoreService相关方法中，出现了很多接受用户输入的代码。

这是不能接受的，如果是在BS程序中，相当于我们把网页写到了service层。

接受用户输入一定是在UI层完成的，修改之后的这两个方法，应该长成这样才行：

仔细比对下之前的save。在调用save方法之前，name和pwd和grade应该在UI层就已经得到了。另外，我也去掉了id，为什么呢？如果你的id在数据库中是自增的，那么根本不需要得到它。当然存在一种情况，我们不需要id由数据库自己生成，而是由代码根据业务特点自己生成，那么确实就应该放在Service的当前方法来生成。但是看这段代码，显然不需要，因为赵同学首先从数据库取id的max值，然后+1，然后再insert回去，那不就是数据库的自增字段吗？所以这样做又是何必呢。

上面的save还可以继续改造

也就是说，service所要参数是UI层已经构造好的对象。到了web阶段，尤其使用了各种MVC框架后，这些对象可以直接由框架构造好，故service层用到的参数是这些实体对象才是更常见的。

2.除了DAO层，任何其它层不要出现SQL

接着来看第二个同样重要的问题

怎么可以这样呢，赵同学，你伤我的心了~~~

你可是一个月写了6篇博客的同学，然而到了这个作业一下子坍塌了，是不是太骄傲导致你看都不看什么是三层架构？

请把所有见得到的 sql 丢到dao层去。

3.Dao层返回什么？

赵同学的作业简直惨不忍睹，把所有能犯的错误全部犯了，如下：

在这个queryall的dao方法中，它返回了一个void，然后列表直接在方法中遍历输出，我只能说一个大大的服

而正常的做法是，返回List<Score>，然后在UI层输出。

除了select，CRUD中的CUD返回什么呢？

Insert、update、delete语句JDBC都会返回一个int值，表明在数据库中影响的行数，举例来说，

如果新增一条记录，则jdbc返回的就是1；

如果更新了10条记录，则jdbc返回的就是10；

而dao就是要真实反映数据库操作，故以赵同学的delete为例

应该修改为：

看到没，我连方法名都改了（哼哼，还有SQL注入哦）。

4.Service怎么处理dao层返回的int值？

Service层不应该再反映数据库的状态了，所以，以deleteByName为例，service应该这么写：

或者这么写：

如果是第一种写法，得有一个全局处理异常的地方，如果是后一种写法，则UI层自己展示删除结果信息给用户。

5.其它问题

A：SQL注入。这个问题就不多说了，用参数化SQL解决之；

B：分层不应该用package，而应该是project，这是作业里面要求的；

C：命名不规范；

暂时就这些吧，如果写多了估计会打击赵同学的积极性，毕竟，我们还要赵同学笑着活下去呢~~