在Java后台编程中,大家一般会使用MVC设计模式,即便使用的具体框架不尽相同。今天,我们来说说MVC中的这个C,也就是Controller。Controller是web程序中最先接触到用户request的地方,当然,前提是该request经过了身份认证和权限检查等重重考验,这一部分建议在框架的Interceptor中进行。详细内容请看笔者之前的博客玩转Spring!从拒绝Filter开始。好了,话不多说,进入正题。
一般来说,Controller的作用是为每个URI提供一个处理方法,比如有一组User的增删改查操作,我们会写一个UserController,然后其中有四个方法,对应User的增删改查操作。好了,这部分没什么不同。我们来看看这四个方法的内部逻辑,比如增加用户addUser方法,我们需要接受一些关于User的元信息,然后检查这些元信息是否非空,是否合法等等,接着调用对应的service方法,然后返回一个执行正确或者执行错误的结果。再比如updateUser方法,我们仍然需要接受一个User的元信息,然后检查这些元信息是否非空,是否合法等等,接着调用对应的service方法,然后返回一个执行正确或者执行错误的结果。
根据Donnot repeat yourself原则,我们自然想到:
1. 可否做一个抽象,将所有的参数合法性检查放到一个地方来做,业务代码仅仅需要指定传入的参数类,框架会帮助检查参数的合法性。如果不合法,直接返回异常。
2. 可否做一个抽象,将所有的返回值放到一个地方来做,业务代码可以将任意的结果类返回,而无需关心该结果类和JsonString的转化。
针对第一个问题,我们设计一种模式,让业务developer每次实现一个URI,就新增一个对应该URI的Param类,然后框架会帮助检查这个Param类。
针对第二个问题,我们设计一个包含泛型结果的类,让业务developer每次仅仅需要将某一个处理结果类放入即可。
至于重用代码的抽象,我们使用回调模式,来看代码:
public interface CommonExecute<T extends BaseParam> {
HttpResult execute(T param);
}
public class CommonExecutor {
public static String execute(HttpServletRe