Vietnam

Here are the "solutions" the above article concluded with:

1. Developers simply give up on objects entirely

Not an argument (by the way it's strange to start with this as a "solution")... ;)

2. Wholehearted acceptance.

This is exactly what a well-design ORM should do: transparency.

For our framework, I found out that SQLite3 was a very good way of some kind of "native" object persistence.
Thanks to unique features of Delphi RTTI, you can persistent dynamic arrays of records in native binary format in our ORM (as BLOB), and even access from it from SQL if needed.

3. Manual mapping.

AFAIK, most ORM allow this. Some via external configuration files, some from code.

I'm currently adding this for our mORMot framework, for any external database, via direct OleDB access.

4. Acceptance of O/R-M limitations.

I agree with that.

That's why I wanted our ORM to have access to SQL when needed, inside our RESTful model.
We rely on SQLite3 and its custom functions and virtual table mechanism to have the full ORM power at hand, even in SQL!

5. Integration of relational concepts into the languages.

This is the LINQ approach.

We tried to avoid mixing syntax in high-level code by simply letting the WHERE (and optionally the SELECT) clause available from the ORM caller.
This is quite powerful:

aPerson := TSQLPerson.CreateAndFillPrepare(RestClient,
   'Points > :(%): AND Points < :(%): AND Active <> 0', [100,200],
   'Name,FirstName');
while aPerson.FillOne do
   DoSomeThingWith(aPerson);
aPerson.Free;

Note that the above code will only retrieve the needed columns (Name,FirstName), so it fixes one issue quoted by this article.

6. Integration of relational concepts into frameworks, i.e. developers take a different view of "objects" that is more relational in nature.

This is an issue of ORM. You should know how to best create your objects.

Another solution: highway to paradise?

In fact, a solution with potential ORM problems is the SOA approach.

IMHO objects are just a way of accessing, via a RESTful front-end, to services.
What is great with ORM is that the same object definition can be used on both Client and Server side.

In fact, you may have several kind of objects, all accessible via a RESTful ORM:
- Low-level DB objects, mapping the database, either local (SQLite3) or remote (via OleDB);
- High-level DB objects, with high-type properties (like dynamic arrays), which are created from low-level DB objects, and optionally stored locally;
- In-memory objects, i.e. short life objects, never stored in the DB, but accessible from Client and Server;
- Services are viewed as objects methods.

So you may have some hidden objects in the Client or the Server side.

If you download the documentation of our framework, take a look at the SAD document.

There are some pages highlighting all those aspects, in the first part of this document:
- MVC and Multi-Tier architecture;
- Why an ORM (with advanced RTTI) - why it is not a DB;
- Why a Client/Server ORM;
- Writing RESTful Services;
- ORM and SQL (via SQLite3 virtual tables, custom functions to access BLOB).

Conclusion

My point is that mixing ORM and RESTful is a good way.

You can do wonders or monsters with ORM, as with any other computer scheme.

ORM is not evil nor good by itself. It's not Vietnam nor Paradise. Can be both, depending on what you do with it.

Feedback welcome on our forum.