Feature branch 23

[butskri]

Placing an order + persistence of OrderPlaced event

[Sch3lp]

Let's not use apache commons equalsbuilder, but guava's Objects.equals. Way back, I read this post that convinced me.

Let's also try to get rid of those casts coming out of the EventStore, like (TrialEvent) eventStore.findAll().get(0)

[butskri]

So, my pull request is rejected? ;-) about the apache commons VS guava thing: I'm a lazy programmer so i'm a big fan of reflectionEquals and reflectionHashcode, even though it has some performance impact. But let's be honest: the database and network overhead of the applicaties we're building has a magnitude of 1000x or more. So I preferer simplicity over performance in this case. Especially when working with value objects, I value the feature that the equalizer and hashcode methods are changed on the fly by just adding a field. When you want to have more controle over your equals/hashcode, I agree guava is a viable alternative.

[butskri]

... Some more on equals and hibernate (however not really to the point for the project we're working on here): I prefer not to implement equals and hashcode methods on hibernate entities. Reason? I think i don't need them because hibernate will make sure it doesn't instantiate an entity which it already instantiated. Suppose i implement hashcode and equals on my entity and let them only check the id field(s). What happens when i am using two instances representing the same entity (at least one of these instances was detached). In that case Hibernate thinks: hey, these 2 objects are equal: let's consider them to be the same object and i will take the properties from one to update my db fields. What happens if i am updating the fields in the other object then? I'd Rather have an exception at commit time in that case instead of hibernate telling me everyting is going fine but my changes weren't updated...

[butskri]

About the casts: the test should be telling me whether mongojack can return me a TrialEvent (a subclass of Event) even though I asked for Event objects (the superclass). Maybe you mean I already tested that with the OrderPlaced event? In that case, you're completely right. The TrialEvent tests should be placed in a class called ExploringMongdbIntegrationTest or something, because they're exploring the behaviour of third party code as described by Uncle Bob in his book Clean code

[Sch3lp]

I wish I could like all these comments.