The following is a simple list of do’s and don’ts:
1 Service
per use-case, should mostly delegate to Commands
.
Commands
implement use-cases or parts of it, and are thus reusable.
Subclass ResourceSearch
, OrderSearch
and ActivitySearch
when implementing use-case specific search - this allows privilege checking.
One Transaction at a time - no TX inside of another TX.
Commands are added to TXs and performed on close: tx.addCommand(Command)
and then tx.commitOnClose()
Only access ElementMaps
if really no other way, mostly use tx.get*By()
, tx.findBy()
and searches - if a specific get is missing, then add the method to StrolchTransaction
and send a pull request!
Use tx.stream*()
methods to iterate over all elements, if you don’t want to use a search.
Don’t write logic in REST API beans. Delegate to other services, making your code reusable!
Marshall to JSON using the StrolchElementToJsonVisitor
.
Unmarshall JSON using FromFlatJsonVisitor
or if needed StrolchElementFromJsonVisitor
References between objects is done by adding a ParameterBag
with the id relations
to the object and then StringParameters
with the value being the ID, the UOM set to the type of element being referenced and the Interpretation set to the class type being referenced.
Very seldom and sparingly use tx.flush()
if you need to perform first some work and then as late as possible call tx.commitOnClose()
The flush()
-method flushes everything, i.e. rollback isn’t possible anymore.