学员会诊之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：命名不规范；
暂时就这些吧，如果写多了估计会打击赵同学的积极性，毕竟，我们还要赵同学笑着活下去呢~~
