ORM equals Antipattern

"So give back to Caesar what is Caesar's, and to God what is God's."

The ORM are not only an anti-pattern, but are an anti-pattern that is poorly implemented.

For example I do not see the need or advantage of SQL replacement with other similar languages such as HQL, JPQL or LINQ. In the case of Java is worse because they are implemented as strings without syntax checking, intellisense or autocompletion in most if not all IDEs. For LINQ would have been better implement syntax checking, intellisense or autocompletion for SQL instead of creating a new language, especially since this has been implemented in SQL Server Management Studio. (That was a pretty stupid decision)

Nor do I see any advantage in replacing SQL to connect and exchange data with DDBB by large XML files or multiple annotations in the code. This is especially painful in Java where there are few or graphical tools for modeling relational model entities. This difficulty is minimized in .NET by using Visual Studio and its visual design tools both in the Code as DDBB First First version, which does not mean it is a panacea.

 
The typical case that exemplifies that the ORM is an anti-pattern is to model an Invoice.
In an approach of traditional OOP Invoice is an object, which contains not only all the necessary data but all the inherent behavior of an Invoice for instance customer data, the destination address of the invoice, the destination address of the products is not necessarily the invoice, shipped products, prices, quantities, discounts, and methods necessary to send the invoice, register in accounting, print it if necessary, etc.

 
In a relational database the information necessary to form an invoice is organized in many tables, People, Customers, Products, addresses, States, Countries, Discounts, etc. Besides the RDBMS have powerful engines to extract and manipulate all these data and the ability to take from them what exactly is needed.

 
What the ORM do is to move all that racket table and turn them into objects housed in the computer memory, so instead you have an object named Invoice now you have a multitude of objects representing these tables and rows of these tables. This does nothing but add complexity to the application, without getting any of the benefits of RDBMS, yet without taking in account penalty in data traffic on the network that this could represent and without the overhead of processing and memory than the ORM itself may represent. Instead of you be talking to the guy, you are talking to the guy who knows a guy and that leads to overload and system slowdowns, among other hardships like having to learn how to map your objects with tables DDBB or write long XML files or fill out the code with many annotations. If a DAO pattern or pattern of aspect-oriented programming could take away most of the data access from POJOs with annotations that are going directly to hell.
At the end you do not get a Relational Model in DDBB and Object Model in your application, but you get two relational models, one in DDBB and another in the application, but also from the point of view of OOP latter model is dysfunctional, defective and anemic.

"So give back to OOP what is OOP's, and to DDBB what isDDBB's."

IMO the most successful approach will be one that allows modeling the data in the relational model according to the rules of this model and take advantage of RDBMS capabilities that provide for the only strictly data necessary for my application using views or stored procedures that are necessary and secondly to model  my domain in the application under the highest OOP rules and then create the necessary connection for these two different worlds can communicate and exchange only  strictly necessary data in one direction or the other, mainly by invoking views or stored procedures that have been designed in the DB.

This would require improving existing APIs to access ODBC, JDBC or (X) DBC data so that the performance of queries to the DDBB be not a difficult and painful task and with the least possible amount of boilerplate code. In addition IDEs should implement these queries with syntax checking, intellisense or autocompletion and graphical tools so that the implementation of these operations on the DDBB be so  easiest and smoothly as possible. This principles will be valid for connection to other sources of different relational persistence DDBB whatever type they are.

Some Useful References:

http://java.dzone.com/articles/orm-offensive-anti-pattern

http://seldo.com/weblog/2010/07/12/in_defence_of_sql

http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

http://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/

ADO .NET Entity Framework Vote of No Confidence: http://efvote.wufoo.com/forms/zyo81zh1qeoxua/

http://www.sqlskills.com/blogs/bobb/mho-linq-to-sql-and-entity-framework-panacea-or-evil-incarnate-part-1/

Inappropriate Abstractions: A Conversation with Anders Hejlsberg, Part VI by Bill Venners with Bruce Eckel http://www.artima.com/intv/abstract3.html

HTML - programming model, mapping impedance mismatch

The main problem that it have and will all JavaScript frameworks will be the HTML itself. HTML has been and is currently a system of text format. His original goal was to format text with links to other reference texts. HTML was not designed to develop applications, but rather to create an encyclopedia that could easily go from one article to another and has remained so after 20 years. Despite improvements in HTML 5, the language is still an archaic and bizarre text formatting system.

At the time when HTML was created there was already a decade since the creation of Graphic Operating Systems, which had evolved from the Operating Systems based in text mode from 60’s and 70’s. As format text language there is nothing to blame, except that in 20 years there not emerged an application like Word Perfect or Microsoft Word where you can enter text into HTML format in an easy and powerful way, but from the point of view of application development, the substrate of HTML is rather deficient, because application development goes back to the time of the screen text mode 40 years before. Would anyone happen he is currently making an application for Windows or Linux console unless it was for administrative purposes and to specialist staff? Well that's what you're doing when applications are developed on HTML.

Then any JavaScript framework can’t solve that underlying problem in the same way that no programming language of 60’s and 70’s could create graphical applications or Event Driven Design applications for an operating system focused on text. After the emergence of graphical operating systems was extremely easy to develop such applications as evidenced by the emergence of Visual Basic in 1991 The emergence of graphical operating systems meant sudden death of a whole suite of applications that had dominated the market in as SuperCalc, WordStar, dBase, etc and gave way to almost complete domination of MS Windows and Office, since those applications were unable to adapt to changing times.

While the substrate on which the Web application is developed be HTML, while the surface on which the application is designed be a “page” of text and the Object of JavaScript which is inserted the rest of elements be a “document”, JavaScript frameworks will have the same faults. It is necessary rethink all this problem and change the text mode paradigm to a graphic one.

En el principio fue

Esto empieza aquí, un blog heterodoxo para reflexionar sobre ciencia y tecnología.