I just read this publish last evening, and that i observed it had been from 2006. I possibly could go in either case around the ORM, database factor, however i only agreed to be wondering if everything bad Shaun stated about ORM still is applicable even today thinking about the publish comes from 2006.

Will still be true.

Much more than OO software, the database suffers whether it is not treated exactly the way intended. Also it wasn't intended that you ought to interpose some abstraction layer before it.

I think about impermeable abstraction layers as attempting to develop a Lego castle with the pieces closed up right into a pillow case. SQL is damn difficult to do properly. It does not share many designs with procedural programming, and finest practices for just one could possibly be the opposite for that other. You have to have the ability to grok each and every item inside a SQL statement, and also have a very good idea how it is meant to do, and what it really actually does.

Many individuals appear to consider that, like horseshoes, close is a good example - when the right answer jumps out, that suggests you are nearly there. In SQL, that's not true.

RoR and also the ActiveRecord pattern have by divine intention gained a status as dbms resource hogs because of this. Enhanced ActiveRecord design is generally suboptimal SQL design, since it encourages SQL statement decomposition.


Object-oriented continues to be object-oriented and Relational continues to be Set-oriented. Nothing has transformed during these two paradigms previously 2 yrs to ensure they are are more effective together.

In lots of individuals eyes, SQL is ugly, complex, and confusing. But attempting to make an item-oriented interface to do exactly the same functionality is definitely uglier, more complicated, and includes a steeper learning curve.

In most programming, there's a tradeoff between versatility and presumptions. Frameworks (for example Rails) attempt to solve the issue when you are "opinionated." That's, they limit versatility of either the relational or even the object-oriented facets of the issue, making presumptions about how exactly information is structured, and what procedures that you can do by using it. Naturally, simplifying the issue space helps make the solution simpler too.

Additionally, it's frustrating to uncover that the ORM framework is incomplete, so some regular procedures in SQL don't have any solution inside a given ORM. This is due to "opinionated" frameworks.

I'm able to only speak for my experience. I personally use DAL and DTO's, and i'm still able to carrying out pretty complex queries (joins and all sorts of), as well as I can turn to SP's or custom SQL whenever I want. It made my existence simpler, my code consistent and my due dates more achievable.

I believe beginning in the assumption that Jeff's conclusions are correct isn't always good getting maintained saved procedure code in addition to JDBC-based data layers, I'm able to state that these triggered maintenance problems in abundance, mostly associated with the lack of ability to know what happening in a greater level.

A database is always low-level it stores amounts and strings basically. Business logic is high-level. For this reason we now have abstraction.

Personally, I believe the Rails/ActiveRecord way is the greatest means to fix getting an itemOrsite model but additionally having the ability to make the most of a relational database.

So: don't get rid of ORM, try not to default into it either. It is a tool that solves certain problems. To disregard it could be ignorant and also to always employ it might be arrogant.

Lots of web 2 . 0. companies are focusing on key-value stores. And all sorts of these businesses need to go using it . painfull procedure for which makes it work.

If ORM may be the "vietnam laptop or computer science" then building your personal key-value store is most likely the "Iraq laptop or computer science" :-)

It does.

I believe the final sentence is easily the most interesting of: "I am inclined to err along the side of the database-as-model camping, because I believe objects are overrated." Java, C++, and C# are extremely the dominant languages, but functional programming is creating a comeback with F#, Scala, etc.