学员会诊之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:命名不规范;

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

评论列表

添加评论

提交评论

服务热线

010-57480310