β

贫血模式下有限富血的所谓proxy模式

从一事无成到仅成一事 64 阅读

为了代码简单,领域模型使用了纯粹的贫血模型,即只包括field定义和对应的get、set方法。(主要原因是当初是先定义数据库表,再用MybatisGenerator生成Java类,因此自己做修改很麻烦)

但是某些与领域模型密切相关操作,又比较适合以类似于富血模式的方式与领域模型绑定到一起。实现某种形式的绑定后,就天然了拥有了领域模型实例本身这个参数,会减少很多代码的复杂度。

最初的动机是:领域模型之间存在依赖关系,例如学生信息中可能存在班级信息的外键,而与之相关的几乎每个交互功能中都存在类似于“学生姓名和所属班级名称”这样的需求。在每个Controller中都写上一个查询方法,非常繁琐,即便是封装了service类,也至少需要在Controller中以某种形式定义一个承载的变量。而我们需要的仅仅是显示而已。

因此,就为这个领域模型配备了一个类,感觉上职责类似于代替这个类做一些事情,因此起名叫proxy。proxy实例要保存一个领域模型的实例,实现绑定。绑定后,就可以在proxy中直接使用,不需要再显式传递。

基类定义:

public ModelProxy(T model)
{
this.model = model;
}

与某Domain类相关联的proxy子类定义:

public DomainProxy(Domain domainInstance)
{
super(domainInstance);
}

领域模型中定义一个getProxy函数,返回与这个模型绑定的proxy类。

private transient DomainProxy proxy = new DomainProxy (this);

public DomainProxy getProxy()
{
return proxy;
}

而proxy类中的方法,命名模仿Java Bean模式:

/**
* 返回学生所有相关班级记录
*
* @return
*/
public List<Classes> getClasses()
{
。。。

}

这样,就可以实现在jsp中直接使用链式el表达式,或者这些信息。

${domain.proxy.classes[0].name}

${domain.proxy.classes[0].proxy.teacher.name}

……

随着开发进行,proxy的内容不仅仅局限于辅助jsp显示。为了防止代码膨胀中造成的混乱,在实践中又总结出了以下一些经验:

Proxy层主要职责:

注:上述两个外键关系,不一定显式的在数据库中存在。也许表结构中没有直接的id存在的,但是按照业务逻辑,会有关联关系

proxy的设计原则:

作者:从一事无成到仅成一事
做一个高尚的人,一个纯粹的人,一个有道德的人,一个脱离了低级趣味的人,一个有益于人民的人
原文地址:贫血模式下有限富血的所谓proxy模式, 感谢原作者分享。

发表评论