Rob Williams is a probabilistic Lean coder of Java and Objective-C. Rob is a DZone MVB and is not an employee of DZone and has posted 170 posts at DZone. You can read more from them at their website. View Full User Profile

Second Phase of Arquillian Mission

04.19.2011
| 3352 views |
  • submit to reddit

The first thing I did in venturing past the weld archetype was to make a simple class that I needed to persist and expose through a REST interface. That went really well (per last post).

I was going to whine about the fact that I have to implement a Repository (as an annotation), a Producer (to expose that repository) and then I have to have some controller class that manually performs the appropriate transactions. This is a bit more time-consuming than the same thing in our old Java EE 5 stack, but it‘s worth it because the annotation gives us type-safe injections. As the docs indicate, you don‘t have to do a Repository annotation if you only have one datasource, but I decided to because I‘d like to follow the protocol for now. On the plus side of this particular issue, the way this thing ends up working, the class that‘s actually manipulating the entities and performing the persistence is a controller. I kind of like that model for a number of reasons. In the 5 genus, we would make a repo for key entities and start adding methods beyond the CRUD ones, and for the larger entities, this interface explodes into a grotesque chimera pretty rapidly. This way, the controllers represent aspects of that entity‘s use in the project. These aspects can be informed primarily by the concept of roles. I am not talking about roles in the security sense, but rather role classes. Example: if I model a Recipe, I have a collection of edible items as Ingredients. Ingredient is actually the role of the food in that particular entity (Recipe). If we were doing nutrition, we would likewise be manipulating Foods (probably the same ones) but from a completely different perspective, e.g. 20% of your protein in this dish is coming from the beans.

The other advantage is that it forces you to test things based on their use, rather than their existential utility. How many times have you heard developers say ‘I just didn‘t know what tests I should put on the entity class? you just fill it with data and put it on the disk.‘ (This also beckons to the Growing Object Oriented Software Guided By Tests protocol: focus on actual value exchanges as integration tests.)

In the second phase, I took on an entity that had a lot more going on: an enum, some temporal types, and relations out to 2 other entities. The process of getting this going was a bit more painful, and I was thinking at one point that maybe the edge of the universe had come up quickly on the windshield, but it‘s working now. Turned out that it was not making one of my tables because I made a temporal field with the name end. That should have been easy to find, but it was throwing another error saying it couldn‘t find a suitable constructor which sent me down a rabbit hole because my prime entity has a Bloch style static builder. Anyway, in the course of doing this phase, I started to think that maybe figuring out all the classes I needed for each test was Arquillian‘s achilles heel, but actually, it‘s not that bad.

This thing is looking better and better….

Here is the basic model: classic association class implementation: Subscribers get a Subscription to a Service.

The Java EE 6 implementation adds a few more items, but is not terribly complicated, and does offer nice separation (per above):

One last thing, the error message about no suitable constructor did get me to verify that this does not need a default constructor, which is nice (peeve of the old Spring test classes).

 

From http://www.jroller.com/robwilliams/entry/second_phase_of_arquillian_mission

Published at DZone with permission of Rob Williams, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: