Author: Bogdan Polak BSC
Declaration Why this blog
I continue the series of introductory articles into the architecture focused on Delphi environment. I was planning to start this blog with a series of posts that may not be revealing, but allow you to put together a well-known pieces of knowledge. Pieces which I did not find online or in the most popular Delphi books, but those that are life-critical for Delphi developers.
OOP projects – What to use: TDataSet or ORM?
Do you like TDataSet? I’m a big fan of it, and it isn’t a shame for me. Now it is not fashionable to admit it, much more cool is to use ORM. Project which using Object-relational mapping libraries are beautiful and easier to maintain. ORMs are useful solution, but firstly, there is no one well known standard and it’s difficult to implement ORM in legacy projects, which are usually taken care of by Delphi developers.
I wrote that there is no ORM standard, perhaps TMS Aurelius becomes a leader. It’s simple, mature, has a lot of functionality, has very good documentation, more and more “getting started” video guides, and many other strong points. However, some developers will not even be interested in it, because they will expect open Delphi OOP solution. There are also OpenSource Daniele DORM and incredible Arnaud mORMot, but DORM has a lack of documentation and misses a lot for Aurelius. mORMot is focused on n-tier solutions and has big learning curve.
The second obstacle against ORMs is much more serious. If we have to implement ORM on medium- and large-scale projects that have been created in whole or in large part using events (according to the EDP paradigm: https://en.wikipedia.org/wiki/Event-driven_programming).
One day I might go back to ORM , but today my architectural choice is TDataSet. You can say that I will write about dataset-centric solutions.
TDataSet Cons
Now it’s time to write about what’s wrong with TDataSet? First of all: events. Events are very intuitive easy to learn and easy to use, but over time they become increasingly heavy. Quoting Wikipedia (EDP article):
The design of those programs which rely on event-action model has been criticised, and it has been suggested that event-action model leads programmers to create error prone, difficult to extend and excessively complex application code.
The events themselves are not so bad, but terrible is that with time consistent domain processes (business processes) are divided between multiple events. This phenomenon is called oversimplification of the event-action model or simply spaghetti-code.
Please read great discussion form stack-overflow about Using Delphi data-aware components – pros and cons. All responses and comments are very informative:
Next time I would like to address the topic of how to fix TDataSet with object-oriented architectural solutions.