Alex Rivera | Logout

How can I design a Java web application without an ORM and without embedded SQL

Asked 2009-04-17T15:15:29.153
63

EDIT: Original Title: Question about the benefit of using an ORM.

I want to use an ORM for learning purposes and am try nhibernate. I am using the tutorial and then I have a real project. I can go the "old way" or use an ORM. I'm not sure I totally understand the benefit. On the one hand I can create my abstractions in code such that I can change my databases and be database independent. On the other it seems that if I actually change the database columns I have to change all my code.

Why wouldn't I have my application without the ORM, change my database and change my code, instead of changing my database, orm, and code? Is it that they database structure doesn't change that much?

I believe there are real benefits because ORMs are used by so many. I'm just not sure I get it yet.

Thank you.

EDIT: In the tutorial they have many files that are used to make the ORM work

http://www.hibernate.org/362.html

In the event of an application change, it seems like a lot of extra work just to say that I have "proper" abstraction layers. Because I'm new at it it doesn't look that easy to maintain and again seems like extra work, not less.

EDIT: This is an old question I keep coming back to. What I want to see if an example of properly designing an application without an ORM and without using embedded SQL and without using .NET LINQ-to-SQL, no offense. I'm in the Java world at the moment, and I'm lost on how to proceed. It is a web application. No Spring, no other worldly frameworks. JSP, JSTL, EL, HTML, JavaScript, CSS, Java, Tomcat. Hope I didn't leave anything out. And yes, I know it is an old question. It is still relevant.

oop design-patterns orm
Edit
Report

1 Answer

123

Why, oh why, is the industry so wedded to this disaster of a concept? None of the previous answers adequately addresses @johnny's concerns. They are all half-baked hand-waving justifications that steer well clear of the concrete issues facing database programmers.

@TheTXI's answer is typical of the responses I get when asking the same question: separation of layers. What is that supposed to mean? Why do I want to separate my layers? Or, more to the point, how does it benefit me to create an additional layer that is different to the relational layer and yet is supposed to be a canonical mapping from that layer?

Furthermore, (@johhny's as-yet unanswered point) how does this protect us from change? If the database changes, the ORM layer will almost certainly have to follow suit. In fact, the default practice of not modeling join tables at the object level makes this even worse, because when the table inevitably grows some extra columns, you not only add some extra fields to the object model, but you also change its topology and force a bunch of code rewrite! This is a disaster for change management and is a classic example of how a misguided view of relations (thinking they represent objects) courts disaster. This simply wouldn't have occurred if you just mapped the relational database directly into congruent notions in the programming language (think LINQ-to-SQL, and not LINQ-to-EF).

The biggest unanswered question in this space — the elephant in the room — is: what problem is ORM supposed be solving? And don't say "object-relational impedance mismatch". That's just another hand-waving fob-off. Explain why there is an impedance mismatch, and why it should be the database that comes to the language rather than the language going to the database. My explanation is that most programming languages suck at expressing and working with relational data, but that this is a historical reality that is beginning to slip aw

answered 2010-04-19T23:14:25.957

Your Answer