Do and Don't

This page discusses things you should and shouldn’t do when using Strolch

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.