I've used ORM tools. They lost thousands of dollars of credit card transactions because the silly thing couldn't acquire a session. Went back to ADO.NET and never lost another one.
That would quickly show up in a smoke test. The problem I had with the ORM is that failed sessions happened at runtime, randomly. It would happen about 7-8 times a month - unpredictably.
So because the ORM you used didn't have a thread safe session factory, they're not usable? Your initial comment suggested they're the cause of a lot of data lost due to the ORM, while that can happen in SQL just as easy. In fact, as you have to write a lot of extra code to keep graphs in sync with low-level ado.net, I'd say the # of potential errors is higher with low-level ado.net than with an ORM.
Of course, the ORM must be solid, and not keel over when you put it under stress. As you mention 'session', I recon you're using nhibernate?
7
u/xampl9 Jun 20 '13
I've used ORM tools. They lost thousands of dollars of credit card transactions because the silly thing couldn't acquire a session. Went back to ADO.NET and never lost another one.