不使用框架，都不会写代码了

昨天在极限编程的群里聊代码测试方面的，突然话锋一转聊到重构之类的话题，云测的一个哥们突然来了一句 “现在很多离开了框架都不会写代码了。” 我给回了一句“用 jdbctemplate 写，领域服务 应用层不用注解，多写几遍就会了。”

然后，开始聊各种 ORM、JPA，我一直不喜欢 Hibernate 、 Mybatis 和早些年使用过的 Struts ，很不喜欢那些配置文件，配置的特别繁琐、麻烦，更喜欢用 JdbcTemplate 简单封装进行编程。

今天接着昨天那句 “现在很多离开了框架都不会写代码了。” 聊聊设计模式中的 Proxy 代理模式。

Robert C. Martin 的《敏捷软件开发 · 原则、模式与实践》对个人的开发影响挺大，就像副标题一样，原则、模式与实践。通过原则与设计模式指导我们对软件代码的重构进行软件的代码异味清扫，从而使得软件清晰可读以及可扩展。

简单案例

商户上架一个商品，系统需要将该商品保存到数据库中。

实现如下：

publicinterfaceProductDao{
voidsave(Productproduct);
}@Autowired
privateJdbcTemplatejdbcTemplate;
@Override
publicvoidsave(Productproduct){
//此处省略保存
}

@RestController
@RequestMApping("/proxy")
publicclassProductController{

@Autowired
privateProductDaoproductDao;
@PostMapping
voidsave(){
this.productDao.save(newProduct(1,2d));
}
}

相信大多数人都会按照上面的方式实现，这种实现站在功能的角度并没有什么问题，假如我们不依赖于 Spring 的注解 @Autowired 该如何去实现上面的业务，同时在 ProductDaoImpl 中，我们依赖了 JdbcTemplate ，能否不依赖呢？

Proxy 模式

代理者是指一个类别可以作为其它东西的接口。代理者可以作任何东西的接口：网络连接、存储器中的大对象、文件或其它昂贵或无法复制的资源。

《敏捷软件开发 · 原则、模式与实践》书中举了实际开发中一个很好的案例。这里我们仍使用上面简单案例进行演示，为了方便看效果，我们增加一个需求是在添加商品的时候，通过名称验证商品是否存在，存在返回 false 不保存，反之则保存。

如图，我们将 JdbcTemplate 交给了代理 PorductProxy，这也就是代理模式解决的问题。代理模式的工作原理，每个要被代理的对象分成 3 个部分。第一部分是一个接口，该接口中声明了客户要调用的所有方法。第二部分是一个类，该类在不涉及数据库逻辑的情况下实现了接口中的方法。第三部分是一个知晓数据库的代理，也就是 ProductPorxy。

示例代码中，proxy 类会直接调用 JdbcTemplate ，采用SQL的方式进行存储。读者可能会问这样不就让 proxy 干了存储，这里仅是为了演示。我们可将图修改如下：

图中的 DB 就是实际进行业务数据存储数据的类。代码实现如下：

Product 接口，工具中类名冲突改成 ProductI

publicinterfaceProductI{

Productsave(Productproduct);
ProductgetByName(StringproName);

实现 ProductI 接口

publicclassProductImplimplementsProductI{

privateProductproduct;
publicProductImpl(Productproduct){
this.product=product;
}

@Override
publicProductsave(Productproduct){
//实际中会进行处理product将处理好的数据返回
returnnewProduct(1,100d);
}

@Override
publicProductgetByName(StringproName){
returnthis.product;
}

publicbooleanisProduct(){
if(product==null){
returntrue;
}
returnfalse;
}
}

代理类

publicclassProductProxyimplementsProductI{

privateStringproName;
@Override
publicProductsave(Productproduct){
ProductImplproImpl=newProductImpl(getByName(this.proName));
try{
if(proImpl.isProduct()){
thrownewError("productnamerepeat");
}
//业务忽略，通过name去查库验证，可使用jdbcTemplate
//或直接调用已封装保存业务的DB
}catch(Exceptione){
thrownewError("productnamerepeat");
}
//为测试方便，直接返回商品
returnnewProduct(2,40d);
}

@Override
publicProductgetByName(StringproName){
//业务忽略，通过name去查库验证，可使用jdbcTemplate
//或直接调用已封装保存业务的DB
returnnewProduct(1,20d);
}
}

测试用例

@Test
publicvoidshould_product_proxy(){
ProductProxyproductProxy=newProductProxy();
assertThat(productProxy.getByName("苹果"),is(newProduct(1,20d)));
assertThat(productProxy.save(productProxy.getByName("苹果")),is(newProduct(2,40d)));
}

通过案例可以看到，ProductProxy 和 ProductI 的行为是一样的，区别在于前者是从数据库中取而不是内存中获取它的数据。

另外，我们将与数据库打交道的交给了 proxy 代理，将重要关系进行了分离，将业务规则和数据库完全分离，ProductImpl 对数据库没有任何依赖，如果想要更改数据库模式或数据库引擎。我们可以在不影响ProductI、ProductImpl 以及任何其它业务规则的情况下进行更改。