Delphi and C++Builder are incredibly productive when it comes to building database applications. However, many people over the years have started to move away from the traditional data-aware control approach in an effort to make their code more maintainable and testable. So instead of having a bunch of code in their forms that interacts with, say, the customer table in their database, they’ll put all that inside a customer object, and keep it separate from the UI logic in their forms.
There’s a lot to like about this approach, however there’s also some downsides. Firstly, you have to come up with some way of connecting your UI to your business objects. Whereas before it was easy to just wire up a DBGrid to your Customer Query, now you have to somehow get the data in your list of Customer objects into your Grid, and back again when someone makes a change. Some people write this code themselves, some people use binding systems like LiveBindings, but there’s no question that for a developer used to the ease of DBGrid<->DataSource<->Query its a big change.
Another negative is on the other side, interacting with the database. You’re now responsible for loading the data in your Customer table into your Customer objects, keeping track of which ones change, and saving it back into the table once you’re done. This isn’t terribly interesting code to write, it’s involved and error prone and ultimately fairly unrewarding. I’ve hand-written more than enough data access code and SQL in my life, so would shed no tears if I never had to do it again.
Object Relational Mapping (ORM) systems have been developed to try and take away the need to write some of this boring, plumbing code, and I’ve worked with several over the years in various languages, from in-house, home grown systems to 3rd party systems. However, when I talk about ORMs with Delphi developers, many times I hear the same set of reasons as to why they can’t use them:
- “They are too complicated”
- “Performance sucks”
- “We need more control over how our objects are stored”
- “They’re fine for a new app, but we have an existing DB structure so can’t use them”
- “Takes too much time. We need to move faster than that”
In this series of posts, I want to introduce you to using an ORM in Delphi and C++Builder, and I hope to try and dispel each of these points along the way. The particular ORM I’ll be using is TMS Aurelius, but the concepts should be applicable in other ORMs.
We’ll start off simply, letting the ORM take control of a lot, but over the series gradually we’ll exercise more control over how things are being stored and loaded. We’ll also look at how you can do all this without giving up your DBGrids. Eventually I also want to get into using an ORM in a distributed application, on both the client and server side.
But first up, let’s get setup and store our first objects into the database.
Pingback: Storing your Objects in a Database – Getting Started – Code Partners
Hi Malcolm,
Thanks a lot for this very interesting tutorial. I was looking for such a solution just about a month ago. I’m heading to get Aurelius. Just one question, since you seem to have been using it in the real world: performances?
Are they as good as the hard-coded plumbing with FieldbyName or declared matching variables (like myDBName.AsString, myDBAddress.AsString) ?
Thanks for any clarification
HI Steve,
I guess it depends. It is always going to be possible to hand-craft faster DB code than using a framework. I’d say a few things about that thought:
1) Many times you don’t need to. In my experience, most client-side DB access code is not performance critical. There are definitely some that is, but that is maybe 5% of cases, so hand crafting it for the other 95% is a waste of time.
2) There is a lot you can do in Aurelius to tune how it’s stored and more importantly, how and when different objects and fields get loaded. I’m going to cover that in future sessions but check out the Aurelius Manual if you want to dig into it now.
3) Very often much of the db code I see is actually part of the problem. Senior developers might have the experience and knowledge of how the DB does it’s query plans, etc and be able to write that code better than the framework, but the majority devs out there don’t. Aurelius in many cases ends up being as good or better than hand written DB access code because you’re leveraging the expertise of others.
For me, it ends up being a case of avoiding premature optimisation. I use Aurelius and get the job done, then I profile the app and see where I need to go in and tune it and worst case, hand write some code. Many times I either don’t need to, or the places I do need to are not the ones I would have picked.
Pingback: Exclusive Offer on TMS Aurelius – Code Partners