Using an ORM? Think Objects!

Monday, July 14, 2008

I recently had some time on airplanes to read through Bitter EJB, POJOs in Action, and  Better, Faster, Lighter Java. All three books were good, but the last one was my favorite, and was recommended to me by Ian Cooper. No, I’m not planning on trading in assemblies for jar files just yet. I read the books to get some insight and perspectives into specific trends in the Java ecosystem. A Sound Of Thunder

It’s impossible to summarize the books in one paragraph, but I’ll try anyway:

Some Java developers shun the EJB framework so they can focus on objects. Simple objects. Testable objects. Malleable objects. Plain old Java objects that solve business problems without being encumbered by infrastructure and technology concerns.

That’s the gist of the three books in 35 words. The books also talk about patterns, anti-patterns, domain driven design, lightweight frameworks, processes, and generally how to  write software. You’d be surprised how much content is applicable to .NET. In fact, when reading through the books I began to think of .NET and Java as two parallel universes whose deviations could be explained by the accidental killing of one butterfly during a time traveling safari.

The focus of this post is one particular deviation that really stood out.

From Objects To ORMs

The Java developers who focus on objects eventually have to deal with other concerns like persistence. Their  object focus naturally leads some of them to try object-relational mapping frameworks. ORMs like Hibernate not only provide these developers with productivity gains, but do so in a relatively transparent and non-intrusive manner. The two work well together right from the start as the developers understand the ORMs, and the ORMs seem to understand the developers.

From DataSets to ORMs

.NET includes includes DataSets, DataTables, and DataViews. There is an IDE with a Data menu, and a GUI toolbox with Data tab full of Data controls and DataSources. It’s easy to stereotype mainstream .NET development as data-centric. When you introduce an ORM to a .NET developer who has never seen one, the typical questions are along the lines of:

How do I manage my identity values after an INSERT?

... and ...

Does this thing work with stored procedures?

Perfectly reasonable questions given the data-centric atmosphere of .NET, but you can almost feel the tension in these questions. And that is the deviation that stood out to me. On the airplane, I read about Java developers who focused on objects and went in search of ORMs. In .NET land, I’m seeing the ORMs going in search of the developer who is focused on data. The ORMs in particular are LINQ to SQL (currently shipping in Visual Studio) and the Entity Framework (shipping in SP1). Anyone expecting something like “ADO.NET 3.5” is in for a surprise. Persistent entities and DataSets are two different creatures, and require two different mind sets.

Will .NET Developers Focus On Objects Now?

It’s possible, but the tools make it difficult. The Entity Framework, for instance, presents developers with cognitive dissonance at several points. The documentation will tell you the goal of EF is to create a rich, conceptual object model, but the press releases proclaim that the Entity Framework simplifies data-centric development.  There will not be any plain old CLR objects (POCOs) in EF, and the object-focused implicit lazy-loading that comes standard in most ORMs isn’t available (you can read any property on this entity, um, except that one – you’ll have to load it first).

LINQ to SQL is different. LINQ to SQL is objects all the way down. You can use plain old CLR objects with LINQ to SQL if you dig beyond the surface. However, the surface is a shiny designer that looks just like the typed DataSet designer. LINQ to SQL also needs some additional mapping flexibility to truly separate the object  model from the underlying database schema – hopefully we’ll see this in the next version.

What To Do?

If you are a .NET developer who is starting to use an ORM –any ORM, you owe it to yourself and your project to reset your defaults and think differently about the new paradigm. Forget what you know about DataSets and learn about the unit of work pattern. Forget what you know about data readers and learn how an ORM identity map works. Think objects first, data second. If you can’t think of data second, an ORM might not be the technology for you. 


Comments
Jimmy Daresta Monday, July 14, 2008
I could not agree more. It was actually thinking of objects that caused me to move to using Linq to SQL (and now with ERPConnect Linq to SAP). Now like you said I can think of the objects first and then the data.
Ahmed Salako Monday, July 14, 2008
The ORM mindset is different from the data centric mindset of manipulating data in any languages. ORM facilities are bridges between the impedance mismatch between the relational world and the OO.

I will suggest that developers using an object oriented language should stop the data centric ways and adopt an ORM framework that can seperate concerns between data and objects.

Not so many ORM frameworks are good today, because some of them make you implement or inherits a certain Interface or class in your POJO level or POCO level which is not a transparent design.

An ORM framework without the On demand functionality (Lazy Loading) is as good as dead. Lazy loading comes handy when you need to fetch objects or data when you really need it. Not all lazy loading are really lazy (ha! ha). Let us say we need to lazy load a colection of customers set in an List, when the list is first called (The Iterator iterates to the Current) some ORM frameworks will load everything you need when the iterator iterates at first time. But thats a bad design concept. Each elemnts in the Current property of the iterator should be freshly lazy loaded from the datastore. I mean if the iterator.MoveNext is called it should get the next object from the datasource and should set it as the current. This approach makes for a better and efficient lazy loading.

ORM technologies must support Multiplicities that is 1:N, N:1, N:N etc Inheritance. Hardly will you see an ORM framework with this facilities except the mature ones.

I started writing an ORM framework 2 years ago, and its due to come out as an Open source framework september this year. I would like many ORM evangelist to contribute to it. Its functionality matches the likes of NHibernate, Java Persistent etc. And it is getting stronger . But some work still need to be done. Util is out.
Michal Talaga Monday, July 14, 2008
Going against the tools is not the best way to go.
Tools for .NET are what they are. Fight it or live with it.
Ahmed Salako Tuesday, July 15, 2008
"Going against the tools is not the best way to go.
Tools for .NET are what they are. Fight it or live with it."

We are in a industry where chaos reigns. This industry needs a saviour, we have waited long enough for someone to take us to the promise land were software architectures, developments are shared across. Believe me or not, the chaos in this industry is affecting careers and giving chances to people who can talk rather than people who can do it.

No one is criticising anyone, we just want the industry to follow what is right. Once its OO development it should follow OO semantics. I think microsoft gets too carried away by the ways they introduces some syntatic sugar. or whatever into their platform. Nowadays its even difficult to differentiate between C# or VB.Net and Visual Studio, can you imagine most people still refers to the .NET framework as Visual Studio. When new cool stuffs in VS comes out, you see many developers jubilating we have done it again.

Lets not forget that languages are different from IDE. If you must use OO language, i believe u should think in OO not data. If the tools are there for a reason, experience have shown that they are there for the wrong reasons. Now ASP.NET MVC is out to separate the Webform code behind concerns, this is because the webform approach is data centric. Entity Framework, Linq to anything is out because microsoft is learning from mistakes. Really we the developers or Open Source fanatics introduces the next microsoft products by singing most things in the air, and adopting it. Redmond chiefs would like to join the party by puting MS infront of anything. i.e MSTest, MSBuild, MSMe, MSWe. Dont forget that these frameworks came out as opensource first. So when experience says Object and not data please do believe, because microsoft will still join the Object party take it or leave it.
Ahmed Salako Tuesday, July 15, 2008
OO
phat shantz Tuesday, July 15, 2008
As a .NET developer who spent two years as the senior architect on an enterprise Java project, I became enamored by Hibernate. My subsequent .NET projects have used nHibernate, Ideablade DevForce, and DevExpress XPO persistence objects.

I have cast ADO aside and will never (repeat, rinse, repeat) never go back to developing like I'm a SQL DBA. No! I am a business application developer and I prefer to spend my brain electricity on solving the business problem, not writing queries that translate my poorly-formed data structures.

This blog makes a very important point: that .NET and Java are very similar, not just in architecture, but in the types of problems each community is trying to solve. Both are burdened (shall I admit) with the same kinds of tools. It is comforting, therefore, that both agree (in principle, at least) on the shape of the solutions.

Unfortunately, I think LINQ is still far too dependent on SQL and the way the Microsoft hive thinks about data. I am grateful, though, that Microsoft's baby steps validate the rest of the industry's long-formed conclusions.

We .NET-ters may be slow, but we'll get there.


Ahmed Salako Wednesday, July 16, 2008
We ask for too much. Having said Data centricness is not good and contributors on this blog post seems to accept that we must all think in objects. For the purpose of transparency, productivity, industry defined standards.

Yet, how do we do objetcs in OOP when Most Persistent Frameworks are not Persistent Ignorant, how do we plan for cross ORM frameworks, when we decorates our entities with attributes, we must implement IBigBoss, we are forced to make our POCO or POJO abstract, we use mapping xml file that are embedded resource in our assemblies (The XML approach is the father of couping because It goes with our transparent POCO'S as embedded resource that does not allow for Refactoring with the range of refactoring tools we have today.

As we proceed,with the chaotic nature of our industry, we realize there is no silver bullet, even though we longed and waited for the most unimaginable miracle to happen, some of us have realized that we cannot wait forever, something need to be done, that is where Open Source framework comes into play.

Recently, i am searching for a Persistent Ignorant ORM Framework, and i realiazed that there is none, even if there is any, the framework will be descriptive [Meaning that you obey do's and dont's].

There have been several long debates going on in the Object Persistent Industry, but there havent been a silver bullet, and there wont be any. Relational is not Object period. So we still need a way to tell the Persistent Engine how the transformation will be done. If Microsoft claims to give us such functionality without the use of Visual Studio to hide the intricacies of the mapping, i bet i will do away with my ORM project.

Most of us (The developers, Analyst, Architects etc) are the root causes to what happened to software engineering today, we envisage a rocket scince, something that cannot be done without plumbing, but have we forgotten that even the JVM's OR CLR's of today is hiding somethings away from us if not, why cant we all start programming in Bytecode or IL or ILasm. Even OOP have its own semantic's which we must follow, if we must use the language. So i wonder why we cannot live by the semantics of ORM mapping and yet we ask too much of the framework.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!