If you consider yourself a developer with principles, then consider this; the use of TDataSet descendants violates the principle of Encapsulation that is foundational to OOP.
Why? Well the moment you drop a dataset onto a form and use an event handler, that form is now tied to that dataset. You might think the fix is to use a datamodule - great idea! The moment you reference the datamodule from your form, the two are tied inextricably together. All you have really accomplished is not cluttering up the form with data access components, and introducing the requirement to reference the datamodule in every data related line of code, or start using the dreaded with and lose the ability to mouse hover to inspect code values. If you think you have separated your data access layer (DAL) from your UI, you have - but only visually. Want proof? Just try to change your DAL components without changing any behaviors in your forms, or one line of form code.
What are the benefits of OOP? If you don’t know, then perhaps you’re still writing procedural code. Delphi’s RAD approach to database development encourages writing such code. Just because a framework uses objects or components doesn’t mean you have to write object oriented code. There are 3 pieces to the PIE when it comes to OOP: Polymorphism, Inheritance, and Encapsulation. Encapsulation enables developers to modify an object in the system without introducing side effects (read code breakage) as long as they don’t change the class interface. Encapsulation is required to write maintainable code. No one can remember all the details of a system even if they wrote it, so without encapsulation, breakage is inevitable.
In a typical TDataSet based application, a central datamodule is used and datasets are filtered dynamically to meet specific needs throughout an application. With the use of data aware controls, the current record of a dataset becomes a significant state to maintain across different forms. Using field and dataset events further complicates the code base, scattering business logic throughout forms, requiring all methods to be aware of the events used, and why, as well as preserving the call chain if they need to tap into an event. In short, it leads to an unmaintainable spider web of undocumented dependencies.
Think you are never going to change your DAL so what does it matter? I guess that means no more Delphi updates for you….