I’m really looking forward to presenting a two day workshop on MVVM in RAD Studio for DAPUG in Denmark next month.

The MVVM sessions I’ve done in the past have all been around 45 minutes long, which is barely enough time to scratch the surface. Two full days will give us plenty of time to get right down into the details of how to build maintainable, testable applications without throwing away all the productivity of RAD.

We’ll build an MVVM application from scratch over several “sprints”, each one focussed on a different area of functionality, and along the way we’ll go deep on issues like LiveBindings, Persistence, Messaging, and more. After two days you should come away feeling very equipped to apply MVVM in your own code.

Full details and registration form is available here.

I realise I’ve been very quiet on the Aurelius front. Not because I’m not using it, far from it actually. I’m using it heavily with and without MVVM, on the desktop and mobile, and even on the serverside behind RAD Server. I made a vow during an ORM presentation last year to never write another line of SQL again, and while I’ve occasionally broken that vow, I don’t think I’ve written a SQL statement in Delphi code since then.

Anyway, I do plan on writing more about Aurelius, it’s on my (large) todo list, but in the meantime, I’ve had questions from multiple people that all seem to come back to the same root issue: understanding how the Aurelius TObjectManager takes responsibility for managing your object’s lifecycle.

I’ve found the best way to make this clear is to write a little test app, so here it is. (more…)

Sample applications are a dual-edged sword. When you’re starting out with some new technology, you want them small and focussed, so you can learn just the single thing you’re trying to learn without getting distracted by unrelated bits.

However, once you know how the individual technologies work, the real question becomes about how you should combine them to build something larger so that it will be performant, maintainable, stable, etc. At this point small sample apps are useless, you want something more “real world”.

I’ve been thinking about this for RAD Server recently. We’ve been doing a number of RAD Server projects for customers, however none of them are applications we can share. What I really wanted, I decided, was a customer to come along who was happy to publicly share all the details about the app we built them. Unsurprisingly, those customers are not that common.

(more…)

In the previous post we got our object loading and saving to the DB, and were able to query and get the results either in a TList<TCustomer> or in a dataset. That’s not bad with such little effort.

However, unless our business domain is fully represented by a single class, we need to look at how you deal with multiple classes with relationships between them. So let’s do that. (more…)

Note this offer is now finished.

We’ve had such a positive response to Malcolm’s posts and videos on Storing your Objects in a DB, that we’ve put together a special offer on TMS Aurelius, the Object Relational Mapper used in the posts. Readers of Malcolm’s tutorials can get 10% off any TMS product that includes Aurelius. This includes  TMS subscriptions, so could add up to a very nice saving. (more…)

If you’ve read the Introduction, you know why we’re here. If you haven’t, it might be worth reading that first because I want to get straight to business in this article.

I’m going to assume you have TMS Aurelius installed. If not, you can grab the trial version here. I’m also assuming you have a database of some sort. I’m going to use Interbase and FireDAC, but Aurelius can work with just about everything so use whatever you like.

Note, if you prefer to watch rather than read, I’ve done a live coding video of what follows that you can watch along with below:

Start up Delphi or C++Builder (I’m using 10.1 Berlin, but this will all work in earlier versions) and create a new VCL application. You can of course do this with FireMonkey on any of the mobile or desktop platforms, but I’m trying to keep the number of new things to a minimum so lets go with something that most people will know. Save the app and call it something like CRM. Next, add a DataModule to the project and save it. (more…)

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:

1. “They are too complicated”
2.  “Performance sucks”
3. “We need more control over how our objects are stored”
4. “They’re fine for a new app, but we have an existing DB structure so can’t use them”
5. “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.