我的书签
添加书签
移除书签16.1 场 景 问 题
16.1.1 登录控制
几乎所有的应用系统，都需要系统登录控制的功能，有些系统甚至有多个登录控制的功能，比如，普通用户可以登录前台，进行相应的业务操作；而工作人员可以登录后台，进行相应的系统管理或业务处理。
现在有这么一个基于Web的企业级应用系统，需要实现这两种登录控制，直接使用不同的登录页面来区分它们，把基本的功能需求分别描述如下。
先看看普通用户登录前台的登录控制的功能。
■ 前台页面：用户能输入用户名和密码；提交登录请求，让系统进行登录控制。
■ 后台：从数据库获取登录人员的信息。
■ 后台：判断从前台传递过来的登录数据和数据库中已有的数据是否匹配。
■ 前台Action：如果匹配就转向首页，如果不匹配就返回到登录页面，并显示错误提示信息。
再来看看工作人员登录后台的登录控制功能。
■ 前台页面：用户能输入用户名和密码；提交登录请求，让系统进行登录控制。
■ 后台：从数据库获取登录人员的信息。
■ 后台：把从前台传递过来的密码数据使用相应的加密算法进行加密运算，得到加密后的密码数据。
■ 后台：判断从前台传递过来的用户名和加密后的密码数据和数据库中已有的数据是否匹配。
■ 前台Action：如果匹配就转向首页，如果不匹配就返回到登录页面，并显示错误提示信息。
提示
说明：普通用户和工作人员在数据库中是存储在不同表里面的；当然也是不同的模块来维护普通用户的数据和工作人员的数据；另外工作人员的密码是加密存放的。
16.1.2 不用模式的解决方案
由于普通用户登录和工作人员登录是不同的模块，有不同的页面、不同的逻辑处理和不同的数据存储，因此，在实现上完全作为两个独立的小模块来完成。这里把它们的逻辑处理部分分别实现出来。
（1）先来看看普通用户登录的逻辑处理部分。示例代码如下：
对应的LoginModel，示例代码如下：
对应的UserModel，示例代码如下：
（2）再看看工作人员登录的逻辑处理部分。示例代码如下：
对应的LoginModel，示例代码如下：
对应的WorkerModel，示例代码如下：
16.1.3 有何问题
看了上面的实现示例，是不是很简单。但是，仔细看看，总会觉得有点问题，两种登录的实现太相似了，现在是完全分开，当作两个独立的模块来实现的，如果今后要扩展功能，比如要添加“控制同一个编号同时只能登录一次”的功能，那么两个模块都需要修改，是很麻烦的。而且，现在的实现中，也有很多相似的地方，显得很重复；另外，具体的实现和判断的步骤混合在一起，不利于今后变换功能，比如要变换加密算法等。
总之，上面的实现，有两个很明显的问题：一是重复或相似代码太多；二是扩展起来很不方便。
