My Life with Isis (so far). Part 2:

“My Life with Isis (so far).”

Did I finally make it and write one of those “catchy” headlines? (*)

When the endproduct is GUI driven, I can imagine that Isis may be a good fit in production as well. At the same time a focus always entails compromise elsewhere.

A downside of every small framework is documentation. For giants like spring apart from the official docs, you can find a myriad of blog articles, youtube videos, a plethora of questions on stackoverflow etc. A not so well known framework cannot possibly cope with this.

Sadly Apache Isis is not an exception. More than once I bit the table as I consulted the wise depths of the internet and ultimately was again being forwarded to the (at that time already known by heart) “Beyond the Basics” page (https://isis.apache.org/guides/ugbtb/ugbtb.html), that did not provide a solution to the problem at hand.

At its core Apache Isis uses DataNucleus (datanucleus.com) as interface to the persistence layer. Again, documentation can’t compete with the likes of the old bull Hibernate.

Something that caused headaches was the lack of inner transactions. Execptionally positive was the response time on the official mailing list, when where we described a specific problem and our solution and asked if that was suitable to use with Isis. Within one or two hours we had an answer!

Another problem, that only occured in production, put a colleague to the test: A very big CLOB, that simply was not created in any testing environment, couldn’t be persisted. Documentation was silent regarding this topic. A workaround was to operate around (the by now dreaded) DataNucleus (which was totally fine in this case as it was no domain object).

During testing the GUI was golden. Especially due to the integration nature of the project, one could easily verify data and with a few clicks ease or even save a long-running retest.

Before I started, the idea of naked objects was foreign to me and I was a sceptic, more so as I moved towards functional programming in the last couple of years, where data and functions are (strictly) separated.

Does it really make sense to build “Fat Objects” again? Where to draw the (business) line? (Customers buy products, should there now be a buysProduct (product) method inside the customer or a buys (customer) inside the product)? If there are no – or at least few – services, how to ensure single responsibility?

I put aside my concerns (as good as I could) and today I can say that the experience was worth it and my scepticism didn’t disappear as a whole, but neither was all confirmed.

As every tool Apache Isis should be used for the tasks it was designed for. If GUI is a minor concern, I wouldn’t use Apache Isis, as this would be like wearing roller skates while stalking the woods: Of course doable, but I would sweat a lot and doubt it makes sense. (Apart from the impact on environment ;))

To get a feeling for a business domain however, or for fast iterations during rapit prototyping, I would short-list Apache Isis. Important to me would be to know, whether the prototype really will be dropped at the end or if the end product is GUI driven.

(*) In case you’re part of a secret agency: Don’t shoot please!

Top