spring和贫血域模型

所以,我注意到我绝对有这样的倾向:像我这样的Spring / Hibernate堆栈对象:

  • Foo控制器调用“FooService”
  • FooService调用FooRepository.getById()方法来获取一些Foos。
  • FooRepository使得一些Hibernate调用来加载Foo对象。
  • FooService与Foos进行一些交互。 它可能使用相关的TransactionalFooService来处理事务中需要一起完成的事情。
  • FooService要求FooRepository保存Foos。

这里的问题是Foos没有任何真正的逻辑。 例如,如果每次Foo到期时都需要发送电子邮件,则不会调用Foo.expire()。 有一个FooService.expireFoo(fooId)调用。 这是由于各种原因:

  • 从Foo获得其他服务和对象是很烦人的。 这不是一个Spring bean,它是由Hibernate加载的。
  • 让Foo做一些事情是很烦人的。
  • Foo是否应该负责select何时保存自己很难。 如果您调用foo.setName(),是否应该坚持更改? 应该等到你叫foo.save()吗? foo.save()是否应该调用FooRepository.save(this)?

所以出于这些原因,我的Spring域对象往往基本上是带有一些validation逻辑的荣耀结构。 也许这没关系。 也许Web服务可以作为程序代码。 也许随着新function的写入,可以用新的方式创build新的服务来处理相同的旧对象。

但是我想逃避这种devise,我想知道Spring的其他用途呢? 你是否喜欢装载时织造(我不舒服)的花式技巧呢? 你有其他的诀窍吗? 你认为程序是好的吗?

您可以使用AOP将Spring注入到Hibernate实例化的实例中。 你也可以让Hibernate使用拦截器来做同样的事情。

http://www.jblewitt.com/blog/?p=129

关于“让Foo事务性地做某些事情是烦人的”,我希望你的服务实现能够知道/关心事务,如果你现在在你的域模型中使用服务接口,那现在应该不是那么完美很烦人。

我怀疑决定何时应该保存域模型取决于它是什么以及你在做什么。

FWIW我倾向于产生同样的贫血结构,但我到了那里,现在我知道可以做一个更明智的方法。

听起来你的应用程序是围绕程序编码原则devise的。 这一点将阻碍你正在尝试做的任何面向对象的编程。

Foo可能没有它控制的行为。 如果业务逻辑很less,也可以使用域模型模式。 事务脚本模式有时是有道理的。

当这个逻辑开始增长的时候,问题就出现了。 将交易脚本重构为域模型并不是最简单的事情,但它当然不是最困难的。 如果你有很多关于Foo的逻辑,我build议移动到Domain Model模式。 封装的好处使得很容易理解正在发生什么以及谁参与什么。

如果你想拥有Foo.Expire() ,在你的Foo类中创build一个事件,比如OnExpiration 。 连接你的foo.OnExpiration += FooService.ExpireFoo(foo.Id)创build对象,可能通过FooRepository使用的FooRepository

真的想想第一。 现在一切都已经到了正确的位置了。

祝你好运!

我认为有一个简单的重构模式可以解决你的问题。

  1. 注入你的服务到你的仓库。
  2. 在返回你的Foo之前​​设置它的'FooService
  3. 现在让你的FooController从FooRepository中请求合适的Foo
  4. 现在给你调用你想要的方法Foo。 如果它本身不能实现它们,请调用FooService上适当的方法。
  5. 现在,通过我喜欢在Foo上调用“bucket bridge”方法(它只是将parameter passing给服务),移除所有对FooService的调用。
  6. 从现在起,只要你想添加一个方法,就把它添加到Foo。
  7. 只有在出于性能原因需要时,才能将其添加到服务中。 像往常一样,这些方法应该通过模型对象来调用。

这将有助于将您发展为更丰富的领域模型。 它还保留了单一职责原则,因为所有依赖于DB的代码都保留在FooService实现中,并帮助您将业务逻辑从FooService迁移到Foo。 在你想把你的后台切换到另一个数据库或内存或模拟(testing)你不需要改变任何东西,但FooService层。

^我假设FooService做数据库调用将是太慢,从一个ORM,如select最近的Foo与给定的Foo共享属性X。 这是我见过的最多的工作。


代替:

 class Controller{ public Response getBestStudentForSchool( Request req ){ Student bestStudent = StudentService.findBestPupilForSchool( req.getParam( "schlId" ).asInt() ); ... } } 

你会走向这样的事情:

 class Controller{ public Response getBestStudentForSchool( Request req ){ School school = repo.get( School.class, req.getParam( "schlId" ).asInt() ); Student bestStudent = school.getBestStudent(); ... } } 

我希望你会同意的,似乎更加丰富。 现在你正在做另一个数据库调用,但是如果你保持学校的caching,惩罚是可以忽略的。 我担心任何真正的OOP模型都不如您正在使用的贫血模型有效,但通过代码清晰度来减less错误应该是值得的。 一如既往,YMMV。

Interesting Posts