domingo, 28 de diciembre de 2014

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:
ADO .NET Entity Framework Vote of No Confidence:
Inappropriate Abstractions: A Conversation with Anders Hejlsberg, Part VI by Bill Venners with Bruce Eckel