Closed marhew closed 7 years ago
In fact many people see ORM as anti-pattern (http://softwareengineering.stackexchange.com/questions/120321/is-orm-an-anti-pattern). The access you mentioned would not be different with hibernate for example.
The real problem in the code base is that the database layer abstraction is not always used and database details are not hidden to the program logic. The helper methods in DbObject are of course not a good idea. However, changing this would not require to introduce an ORM. For example you could have a look at more lightweight alternatices like http://jdbi.org/sql_object_overview/ or https://www.jooq.org/.
A more useful refactoring would be to introduce a Dependency Injection framework. This would solve the problem that for many tests a complete scenario is written to the database. This is critical since it prevents fast unit testing.
Hey, nice to here from you 👍 I opened another issue to discuss persistence. I will also add an issue to discuss testing.
When we started working on the Chimera case engine the team thought it would be easier to write "some SQL statements" themselves, instead of learning to use Java Persistence API (JPA) and a object-relational mapper (ORM) like hibernate. The SQL statements grew into kind of a home-brew persistence layer in the package
de.hpi.bpt.chimera.database
. This turned out a bad idea 😔The goal of this epos is to replace the custom persistence code with a framework like hibernate or eclipseLink and refactor the code to not longer use things like
DbFragment.getFragmentsForScenario(3)
.