5 ms·
I've worked on a 2-layer warehouse management system written in PL/SQL on the backend with very thin C++ layer in Qt 3 on the front end. It was pretty nice, th
by ajuc 6y ago
I've worked on a 2-layer warehouse management system written in PL/SQL on the backend with very thin C++ layer in Qt 3 on the front end.
It was pretty nice, there was a proprietary framework to use one XML file per form with SQL and metadata to generate CRUD with SQL-backed grids, filtering, sorting, and simple actions, and everything else was added with straightforward C++ Qt code.
Almost all business logic was in PL/SQL. It was simple and quick and the divisions were obvious.
We moved it to 3-layered Java code with SQL (and some PL/SQL still) on the backend, then Jboss application server and EJB3 code, and Java Swing forms on the frontend.
The goal was to eventually move all business logic from PL/SQL to Java and avoid Oracle Tax (it was before Oracle bought Java BTW - funny how that worked out :) ).
That all would be fine, but our architects bought the cool aid and decided to overengineer the crap out of this software.
What was PL/SQL + 1 XML file + 1 Qt form became like 10 layers of XML files (1 specifying how to get the data from database, another how to transform it to DTO format, another how to represent it on the frontend, another what actions should be possible on it in the frontend, another how to transform from DTO to action object for each action, etc.
Yes you had to write less code in edge cases than in the C++ solution, but instead you had to juggle over 10 XML configuration files even for simplest cases where before 1 SQL wrapped in XML was enough.
It wasn't 3 layers of abstraction - more like 12 in practice. And all that configuration bought you was the ability to potentially write slightly less code when using several forms together and passing data between them (which we almost never did anyway).
It was developed for years and finally shipped (I think), but only to one customer out of dozens and we completely switched the technology again soon after for unrelated reasons.
- deleted 6y ago[deleted]
- UK-Al05 6y agoOne the worst systems I worked on was tons of untested PL/SQL. Could not change anything without unknowingly breaking something.
- ajuc 6y agoIt was pretty good code as far as PL/SQL goes. All the functions were divided into packages and followed this template: function (inParam1, ..., inParamN, outParam1, ..., outParamN, outMessage): ReturnType begin savepoint SP_begin; -- do stuff outMessage := '...'; return RESULT_OK; exception when ... when others then rollback to SP_begin; outMessage := '...' || exception details || ' ...'; return RESULT_ERROR; end; It's funny how I remember this after more than 10 years :) Made it very easy to add tests and to interoperate with container-managed-transactions in EJB3. I even added an debug-only interceptor on EJB that created a savepoint before calling any PL/SQL and checked if that savepoint was still valid after the call. If no - that's a PL/SQL that isn't following the template and the developer who changed it needs to be flogged ;)