I’ve been working with Entity Framework for about 9 months now and I don’t think I can go back to a data access layer that relies on SQL strings and stored procedures. The benefits of using an ORM (Object Relational Mapper) over using traditional SQL and generic data access objects are overwhelming.
- strongly typed data entities, no looping through arrays with hard-coded column names to retrieve data
- compile errors on critical database changes
- intellisense, code hints and compile warnings
- less code to write in general, especially when casting and joining tables
- more semantic code, easier to read and comprehend
- automatic data class (model) updates from database
I just gave a demo to my coworkers and there was a mixed reaction. Some DBA’s looked a bit nervous. “You can build apps without SQL? But SQL is what I write! Will this make me irrelevant?” Fear not, gentle DBA. We still need reports, nightly scripts, backup procedures, data migration, triggers, optimization and many other things that require intimate knowledge of database architecture. But we don’t need 3 stored procedures to update every table. I think this will actually free DBA’s from the more mundane tasks so they can focus on architecture and other concerns.
ORMs are not perfect and they come with their own unique challenges, but they are nonetheless a giant step forward.
The Object Database
Another not-so-new technology that’s been gaining traction is the Object Database. Many experts are saying, why bother mapping objects to relational data tables when you can just save the object directly into the database? It makes sense and it is quite possible that object databases are easier to use than ORM’s with a relational database. They’re apparently quite efficient at serializing and querying data.
The main anchor keeping this technology from taking off is the need to support legacy systems, and DBA’s who are unfamiliar with or uncertain of object databases. With ORMs, a programmer can evolve their code independently of the database. Entity Framework just released support for POCO classes, which is a fancy word for regular classes you write yourself. Writing the classes yourself allows some extra freedom, but loses some of the automation that makes the framework cool and easy. One reason this feature was included was to allow developers to ease the ORM into a system that already has classes built, then to slowly replace their old SQL with LINQ.
Either way, ORMs provide a visual editing tool to represent data relations, and a tool will always exist for this purpose. With Entity Framework, you can actually generate the database from the models you design, so it’s quite likely that there will soon be a “switch” behind the scenes to simply generate an object database instead, and there will be little to no effort for the programmer. Switching to ORM makes a system more prepared for an upgrade to an object database. More and more reporting and analysis tools will likely begin to plug in to the ORM directly instead of the database to employ the same benefits.
The Bottom Line
The bottom line is the same. Object databases and ORMs require no SQL writing. I don’t think SQL will simply vanish or that the skill will lose value right away. But it could gradually go the same direction as Regular Expressions. The need to write SQL will become less frequent, and the tools to aid in the process will continue to improve. Of course an understanding of the SQL language will aid any developer working with an ORM or any other visual tool in much the same way that an understanding of HTML markup aids the use of visual web page design software.
So, no, I don’t see SQL simply going away any time soon. It’s far too entrenched and it will be decades before all legacy systems begin to migrate away. But don’t be surprised if you begin to see job descriptions begin to pop-up requiring knowledge of Entity Framework, NHibernate or other ORM’s.