DCI和服务Services (EJB)

DCI and Services (EJB) | Javalobby

DCI(Data Context Interaction)可以提高面向对象代码的可读性,但是没有对象事务 安全 并发 可伸缩性 可靠性有一些具体的规定。

而服务,也就是EJB和Spring中无态服务有这方面规定,并且可提供切面AOP将这些通用功能引入到业务服务中,这样让程序员更关心业务代码。

但是,服务约束了开发者以对象等更高方式来思考,而DCI更加符合OO,如果想让对象有一些行为,可以使用DCI,而不必将对象传递给服务。

如果对象需要提供丰富的行为,如事务处理等,也许这个时候就需要和服务一起使用。

DCI中的常见逻辑上非常类似SOA中叫服务的东西,但是并不是真正对应,DCI中封装的行为将和场景以及当时角色一起;而在SOA中,服务只是封装它自己,没有这么多因素。

文章使用一个火车能量消耗预测模型来说明DCI和服务的结合使用。这个需求没有对快速计算等功能要求,只要求我们使得其有次序,所以,面向对象方法可以派上用场。

完整代码案例可以啃啃原文,这里大概说一下,可能不是太准,以原文为主,在一个EJB服务中调用DCI代码如下:


@Stateless
@Context
public class ForecastingContext implements ForecastingContextLocal {

/**
* an asynchrounous method for determining the energy requirements of the given trip.
*/

@Asynchronous
public Future forecastEnergyRequired(Trip trip) {

BehaviourInjector bi = new BehaviourInjector(this);

//场景将实体对象下塑为角色,开始交互行为
//DCI典型调用方式
EnergyConciousTrip t = bi.assignRole(trip, EnergyConciousTrip.class);
double energy = t.forecastEnergyRequirements();

return new AsyncResult(energy);
}
}

案例中使用EJB,这样能够提供场景所需要的事务 安全等功能,同时结合文章作者的BehaviourInjector 框架。

这是一个场景能够使用服务这样组件技术来表现的案例,如果这样案例合理,那么企业就可以建立将场景库和服务库建立在一起。

有人可能疑问:难道创造角色将行为注射到Train这样实体中,肯定好于直接将这些行为方法放在服务中?作者没有回答。(banq注:这其实是贫血模型和充血模型区别,见这个讨论:对领域驱动设计的初步认识(六))

文章最后附有源码下载观摩。