Java Web实战 | MVC案例：用户登录验证

■ 图7-3多层架构示意图

在jdbc数据库中创建一个名为account的数据表，用于存放用户名和密码。建表语句如下：

创建一个实体类Account，用于封装用户名和密码信息。其作用就是MVC中的M(模型)。代码如文件7-1所示。

【文件7-1】Account.java

专注于数据访问功能的组件称为DAO

(Data Access Object，数据访问对象)。为了避免应用程序与特定的数据访问策略耦合在一起，一个良好的设计方案是数据访问组件以接口的形式暴露功能。图7-4展示了数据访问层的合理设计方案，业务逻辑对象本身不会处理数据访问，而是将数据访问任务委托给数据访问对象。业务逻辑对象通过接口来访问DAO组件。

■ 图7-4数据访问层的设计方案

这样做会有两个好处。第一，业务逻辑对象易于测试，因为它不再与特定的数据访问组件绑定在一起。第二，持久化方式的选择独立于DAO接口，只有数据访问相关的方法通过接口暴露。这样的设计更加灵活，并且切换数据访问层的实现技术不会对应用程序的其他部分产生影响。如果将数据访问层的实现细节渗透到应用程序的其他部分，那么整个应用程序将与数据访问层耦合在一起，从而使得设计僵化。

针对数据访问层，本例使用Druid数据库连接池。接下来，创建AccountDao接口及其实现类，规定用户登录时要执行的数据库操作。由于DAO负责数据的存取，它也可被视为MVC中的M(模型)。AccountDao接口的代码此处省略，下面给出接口的实现类代码，如文件7-2所示。

【文件7-2】AccountDaoImpl.java

业务逻辑层的Service组件用于处理用户请求，并返回处理结果，可以被视为MVC中的C(控制器)。业务逻辑层与数据访问层的设计思路类似，需要设计的是Service接口及其实现类。这里的Service接口代码简单，因此只给出Service实现类的代码，如文件7-3所示。 

【文件7-3】AccountServiceImpl.java

如文件7-3所示，因为Service组件需要数据访问(DAO)组件提供的服务，所以第8行将数据访问对象AccountDao作为私有属性并实例化。用接口声明是一个良好的设计方案，这里需要注意的是，Service组件只需要一个能够提供AccountDao功能的组件，而非具体指明是哪个组件。如果用下面的代码来声明：

则这种声明语句指明了具体的组件，显式声明了当前Service组件要用到AccountDaoImpl组件完成任务，这样会造成两个组件的耦合性增强。

 第8行的写法降低了组件间的耦合性，并且由于数据持久化的实现由AccountDaoImpl组件负责，独立于AccountDao组件，由此带来的另一个好处便是在满足AccountDao接口要求的情况下，可以灵活替换数据访问组件。

Servlet用于接收用户的请求，并将请求参数封装后交给Service组件进一步处理，它也是MVC中的C(控制器)。创建Servlet的代码如文件7-4所示。

【文件7-4】LoginServlet.java

如文件7-4所示，第23~26行获取请求参数，并把它们封装到Account对象中。第28~37行完成用户是否可以正常登录的判断，从而跳转到对应的页面。

创建表示层组件JSP，它是MVC模式中的V(视图)。在src/main/webapp文件夹下创建名为login.jsp的JSP文件，设计用户登录界面，代码可参考文件3-14，此处略。

最后，可以利用浏览器查看程序运行的效果。本例主要向读者展示如何应用MVC设计模式开发多层架构的Web应用程序，对于数据库保存用户密码的加密问题，用户登录权限的判断问题等都没有涉及，读者可结合过滤器等知识自行完成。