CODEWITHSUNDEEP
jakarta-eejava-ee-6cdijava-ee-7
andbi
andbi

Reputation: 4454

Java EE CDI, packaging and code readability, best practices

Recently I've started to migrate one of the ongoing Java EE projects towards more intensive usage of CDI concepts (events, producers, disposers, qualifiers, etc) and after a week of an intensive coding I finally found myself lost in my own code: what produces what, in which scope, who observes particular events, etc. And on the top of the above - the understanding, that, with all these events, the concept of execution flow is way less applicable for CDI. All in all it's much like losing control of the code.

Being generally satisfied with the ideology of CDI, I'd like to ask you how do you generally handle your CDI projects, what are best practices in packaging CDI entities, in cross-module visibility (web, ejb, common libs) and in making the code more readable and understandable. With this regard I'd appreciate any good articles or ideas from your personal experience.

Upvotes: 1

Views: 737

Answers (1)

Karl Kildén
Karl Kildén

Reputation: 2435

May I propose that you download the source code from Deltaspike project? This is a high level projects from many of the best CDI experts out there and you might pick up a thing or two from their structure.

https://deltaspike.apache.org/documentation/source.html

Work on getting good package names and maybe links in your javadoc so you get breadcrumbs.

What worked for me was to reduce my events a little and use more @Qualifiers Often my events where very similar and my @Qualifiers made sense in many contexts.

But really a part of inversion of control is exactly to not have control. Maybe you don't need to be sexy and produce stuff with different scopes and such all too much, that sounds hard to remember.

Upvotes: 1

Related Questions