I am new to Flowable, actually new to BPM domain. My first work is to duplicate the Flowable IDM module and customize it to as my Company requirements.
I started the job and everything works fine but I am really worried about the DAO part of this module and I think that the other modules in Flowable also uses MyBatis on DAO part. I really hate ORM frameworks. I have used Hibernate on many projects and MyBatis is something similar to it. At the same time I used Spring-Data on many projects and I can definitely say that it is the most suitable library for these kind of things.
Another thing I recognized for the DAO part is; you have abstracted things way too much and it is really becoming hard to follow the steps of the developer he takes. Let’s say if I want to add a new property for a User Entity I need to make change in at least 10 different java files. I am not even mentioning the js and html files.
My question is; do you have any consideration about replacing MyBatis in future releases or are you really happy with this and keep going on that?
Everybody has his/her own preferences for frameworks and patterns etc. For Flowable it’s important that we can control database transactions and the SQL queries on a fine grained level and when we started with Activiti 8 years back (and now continued the project with Flowable for close to 3 years), the choice was made for MyBatis, also because we didn’t want to bind the core engines to Spring. Looking back, we are really happy with the choice for MyBatis. Would the same thing have been possible with Spring Data? Yes of course.
It’s correct that when adding a property to the User entity (or any other entity) requires changing a lot of files. This is because we have implemented several layers in the service to data logic, because this makes it possible to override for example the data classes and replace them with a MongoDB persistency layer (https://github.com/flowable/flowable-mongodb), without having to change other layers and the same service interface can still be used. The downside is that adding a new property to an entity requires more work, but is most cases this is what the Flowable project does and not the users of the Flowable Engines.
I try to keep calm every time I review the engine modules. It is like reinventing the wheel, discovering america back again. I am not mentioning the code quality, it is well written, flexible and modular but seeing those if conditions written according to db types, db brands etc makes me feel uncomfortable that if you may forget checking one more condition that you couldn’t decide at that time. Another thing i didn’t understand is if you don’t want to depend on spring framework why did you prefer spring transaction api in engine modules.
As you said this is a framework you are developing and you do the all the work whatever it costs but this approach will make developers exhausted at a time and me as a contributor to another projects on github may not feel to contribute in these type of projects. Just saying
In the end thank you all for the great effort you make
