Domain rich applications without ORMs

Question

I am relatively new to the world of software development. I am currently on a project, which is quite large, and it's decent OO code - mostly following Domain Driven Design principles. However, often while this sounds great in theory, practically the whole Object Relational Impedance is pretty bad, and it means some parts of the system are quite slow using just the ORM layer, unless we write optimised SQL queries to cover those cases. Also, sometimes we seem to be stuck trying to see whether we should model the domain based on SQL's performance vs OO principles.

This makes me ask this - is this the way most applications are built? Meaning - yes, OO is well and good - but I find it hard to believe that with all the problems associated with this Object relational mismatch, is this the best way to build apps? The alternative approach I can think of is to ditch the ORMs and just have domain modelling, and writing native SQL queries directly by hand uniformly. I would like to know if there are actually software systems of sufficient size being built this way.

I am sorry if I sound n00bish - but I am new and would like to know what other approaches are there.

Answer 1

Don't apologize for recognizing the obvious. Those with far more experience often utterly fail to recognize what you have: ORM is bad engineering, for exactly the reasons you specify.

But I don't want to descend into a rant. The arguments against using embedded SQL range from stylistic, "i don't want that garbage in my code" to, um, stylistic, "SQL is ugly." But it works, it's fast, and it's good engineering.

Answer 2

One can use both.

To be honest, for simple single record modifications and views (including display of related entities), the ORM generates pretty much the same code as I would write by hand. So the advantage is of course that I don't have to write it. Plus, minor schema modifications are handled gracefully.

For everything else, plain SQL is king.

I'm of the opinion that any code that can be generated, should be generated, as long as it doesn't produce a clearly substandard version. I think this is my key point: A significant amount of an application's database code, can be delt with by an ORM and still perform equally well as hand crafted sql code written by a database expert.