Hace poco hubo una discusion sobre el tema en:
"What ORMs have taught me: just learn SQL"
https://news.ycombinator.com/item?id=8133835
---
Hay varios tipos de ORM. Es muy practico tener un objeto, y darle .save() para no escribir el UPDATE/INSERT manual y hacer el
escape de parametros y todo eso. Pero hay muchos ORM que son mas complejos y terminan complicando mucho las cosas al final.
Un ejemplo de una capa quasi-orm bien hecha es SQLAlchemy (core):
http://docs.sqlalchemy.org/en/latest/core/tutorial.html
Notaras que es muy similar a hacer SQL, solo que con ciertas comodidades para ajustarse a un lenguaje OO (en este caso python). DataAbstract va por este camino.
Diseñe un ORM hace un rato para iOS:
https://code.google.com/p/chibiorm/ y en el camino he ido haciendo ajustes a la idea. Un problema es que los lenguajes OO tienden a hacer complicado este asunto y Delphi, en especial. Python permite darle vueltas y es facil de hacer algo como sqlAlchemy, pero Delphi es muy rigido!.
Ademas, que el modelo "relacional" que implementan las BD actuales es incompleto! Y el puenteo de los lenguajes ademas sufre por ello. Hace poco vi un buen articulo sobre el tema:
http://www.try-alf.org/blog/2013-10-...-class-citizen
----
En resumen? Considera la BD tal cual un servidor remoto. Encapsula las llamadas en funciones, no hagas concatenacion de strings para los SQLs, si tienes un engine potente como postgresql abusa de todo lo que tienen (como funciones y procedimientos). Tener algo como sqlalchemy o LINQ (
http://www.linqpad.net/whylinqbeatssql.aspx) seria ideal, pero de lo contrario algo como:
Código Delphi
[-]
function obtenerListaClientes:TDataset;
function buscarCliente(campo:String, comp:Enum(=,<,>, etc), valor:?):TDataset
function guardar(Objeto:?):Bool
function borrar(Objeto:?):Bool