Funny statements regarding Database and ORM

Twitter is great to share things that's hard to misunderstand. 140 characters are just inadequate to explain your philosophy of software development, even a series of tweets. Is a meaningful tweet to you also meaningful to your thousands of followers?

I saw a series tweets from Uncle Bob Martin today and found them very confusing to me, and maybe misleading to others.

Databases are details to be hidden. They are not your central abstraction, nor are they the core of your application. Ever.

In any multi-tier software architecture, lower tier provides service to the tier that sits on it. Upper tier defines the contract for lower tier to implement, rather than vice versa. Databases, as a repository service, is by no means a central abstraction, or the core of the whole application. Otherwise, my garage is the core of my house because I store everything there.

But, databases provide an abstraction (no central here) to the tier just above the database layer. As long as the JDBC URL (from a Java developer's perspective, luckily Java is still popular in enterprise software development) is not used outside data access layer, we can say databases are hidden.

Personally, I really don't know how not to make databases hidden, how not to think databases are not central abstraction, or not the core of an application.

relational tables hold data structures, not objects. Objects are bags of behavior. Data structures are bags of data.

I think he wanted to express either relational tables hold data structures, not classes; or relational tables hold structured data, not objects. But anyway. Relational tables don't hold objects / classes is just the reason why we need ORM to map them to objects / classes, and operate hidden data though interfaces.

Any bridge is used to connect two different entities. ORM is the bridge between data and objects, or tables and classes. If the mapped objects don't provide something else convenient to application development, why do we do the mapping? From a bags of data to another bags of data? Yes, we can. But only in mapping to something like C.

The O in ORM is in error. It should be DS for Data Structure. No simple tool can map tables to objects.

Here comes the funniest part. Everyone knows ORM is first introduced in Java. That's easy to understand why ORM has a O in it. Java doesn't have struct keyword, so it's ridiculous to criticize the naming of ORM. Can't we teach Data Structure in Java? The getters and setters in mapped objects are not behavior?

Unless you apply Domain Driven Development, there are no operations other than getters and setters in mapped objects. Even if you apply DDD, the operations in mapped objects are not mapped from table, they come from business rules. For example, what, in a User table, can be mapped to a addUser() behavior in User class? Don't tell me it's mapped from a stored procedure called add_user. We're talking about tables, right? Stored procedures live inside database, but outside any tables.

If anyone really likes this kind of naming game, here is a free topic for you if you have thousands of followers like this guy. The disk in RAM disk is in error.

Have fun.