In his "Law of Repetitive Consequences," famed Spanish philosopher George Santayana stated that those who do not remember the past are condemned to repeat it. As noted in the excellent book, Persistence in the Enterprise: A Guide to Persistence Technologies, the converse of this often-paraphrased aphorism—"those who do not study history may not be able to repeat the successes of the past"—is uniquely suited to the software engineering arena. Without the willingness and ability to learn from and expand upon previous achievements, developers are likelier to needlessly exhaust time, effort, and valuable resources to achieve similar measures of success. It is a continuing challenge that crosses every software development spectrum and touchpoint, from the simplest script to the largest, most sophisticated enterprise-level solution.
This is not to say, however, that this seeming inability to take a page from history is an obstacle that cannot be overcome. As the world of software engineering continues to mature and evolve, a shift is taking place: Developers are finding newer, better ways of learning from, reusing, and improving on previously proven technology breakthroughs and processes. The result? Better-engineered projects completed faster with fewer resources.
Nowhere is there clearer evidence of this transformation than in the paradigm shift currently taking place in Object-Relational Mapping (ORM) tools. ORM use is on the rise, thanks to the realization that an evolutionary change is ongoing. Much like a chameleon sheds its skin, ORM is leaving behind its reputation of high-end, abstract toolsets designed for use in only complex, top-level enterprise-wide projects. Instead, ORM is metamorphosing into a best-of-breed productivity booster, a reliable bridge to greater accuracy and efficiency.
The ABCs of ORM
When talking about any concept, innovation, or object, the natural first step on the path to understanding is definition—answering the questions of what, where, and why. What is ORM? When and where should it be employed? Why should developers consider leveraging ORM in their projects?
ORM can fundamentally be defined at length as tools that map "objects"—object-oriented classes—to the "relational"—database tables—while functioning as a conduit by "mapping" between different system architectures in relational databases, relational database management system (RDBMS), and OOP languages. This intermediary channel improves access and management of objects throughout the code by freeing developers from the need to continually account for new or modified changes to project data schemas. A shorter, easier to remember definition can be phrased as the ABCs of ORM:
- Abstraction: ORM is based on abstraction: It allows developers to manipulate and manage objects without requiring consideration of relational linking to an associated data source.
- Bridge: ORM creates a bridge between OOP capabilities and the underlying relational database and RDBMS it serves.
- Consistency: With ORM, developers maintain a consistent view of objects, despite changes and updates to the associated schema.
Having put a definition of ORM in place, the next question to be addressed is where and when it should be leveraged. Only several years ago, ORM was relegated to and intended for large, complex projects with intricate architectures and that required significant amounts of data handling. As today's emerging generation of ORM tools continue to evolve, they are becoming more nimble and easier to use, prompting more developers to take a second look at integrating ORM into their application architectures. There is also a steady migration underway, moving ORM away from just larger, high-complexity projects into smaller, less elaborate settings.
With this newfound relevance for projects of every size and scope, it is reasonable to suggest that ORM can be deployed effectively at any time when interaction with data is required. While there are specific situations where ORM is an ideal option, such as when there are relational databases from multiple providers in play, circumstances and personal or organizational preferences will always be the final determining factor as to whether ORM should and can be used.
When talking about the "why" of ORM, there are a number of tangible advantages and benefits that make it a viable, constructive development choice. Just a few of the gains generating greater coding efficiency and improved productivity include:
- Mitigation or elimination of repetitive development tasks, lessening the amount of resources that must be devoted to their completion, thereby accelerating the development cycle.
- Cleaner, more portable and scalable code; by enabling easier generic code development, ORM encourages code reuse, reduces the amount of re-engineering needed, and facilitates scaling to accommodate projects of varying size.
- Reductions in code bloat—for example, as highlighted on numerous websites, blogs, and online forums, ORM permits developers to focus on their project's business logic rather than concentrating on Create / Read / Update / Delete (CRUD) logic, shrinking the number of lines of code needed.
- Simpler template design, more streamlined page structures, and better overall system management.
It should be noted that to realize optimum benefit, ORM does require developers to have a certain level of proficiency with their product's ORM framework. However, ORM tools can also act as an equalizer; depending on what their given ORM supports, developers can work effectively within multiple diverse environments, such as SQL Server and Oracle, without requiring specialized knowledge of each database system. Therefore, with inherent framework knowledge and familiarity with their chosen tool, developers will find that ORM truly delivers on the promise of efficiency, effectiveness, and accuracy, regardless of the back-end configuration.
Moving Forward by Looking Back
If developers and the industry at large are to remember and learn from the past, taking a look at the history and ongoing evolution of ORM is a necessity. First conceived in the 1970s, ORM's practical introduction in the early 1990s aimed to address a functionality gap—the lack of an effective means of managing both objects and relational data—as well attempting to reduce the layers of complexity many developers face in data-driven applications. State-of-the-art at the time, early ORM tools were often broadly defined and loosely focused, complicated, and with only rudimentary functionality. Further, these first ORM toolsets centered around programming objects rather than on behavioral logic and frequently were more intimidating and time-consuming than they were beneficial.
With its daunting nature, ORM was very off-putting to many developers. As a result, its usage was at first limited to a fairly exclusive club of "uber geeks", exceedingly intellectual OO programmers working on vast, multifaceted enterprise-level projects with large, complex databases. Yet, despite this restricted universe of potential users, a number of pioneering ORM technologies and vendors emerged, such as TopLink by Canadian consulting firm, The Object People, and the ObjectLens toolset offered by ParcPlace Systems.
The current gravitational shift toward greater acceptance and adoption began in earnest with three key events: the release of Java, followed by the launch of the Hibernate ORM library, and finally, Microsoft's unveiling of the .NET platform.
A disruptive technology, Java's debut marked an abrupt shift in the way developers and users think about access to applications and data. While Java pioneered the concept of "write once, run anywhere", its true value lay in the visionary thinking behind the Java Virtual Machine (JVM). The JVM asserted a radical idea: that the hardware and memory management could be abstracted away from the development process. It was a concept that shook the development world, and Java and JVM quickly gained a loyal following among numerous developer constituencies, such as enterprise software developers. The flexible, easy-to-use platform also sparked the rapid development of complementary toolsets and libraries, including the popular Hibernate ORM library.
Created collaboratively by a global team of Java developers, Hibernate presented an exceptional mapping framework for OO domain models and relational databases. With the emergence of Hibernate, developers were given the ability to use ORM in smaller, less complex projects, helping to fundamentally reshape their perception of ORM and paving the way for today's generation of tools and libraries.
Java and Hibernate are both critical in its evolution, however, the introduction of Microsoft.NET also played a fundamental role by unlocking ORM for the masses. Less focused on the OO archetype, .NET integrated much of Java's best functionality, while simultaneously simplifying the transition from Windows to web-based environments for developers. The release of .NET was quickly augmented with ports of existing tools, such as NHibernate, and Microsoft itself raised the bar for ORM by introducing innovations like LINQ to SQL, and multiple configuration and visual GUI improvements.
With the migration of ORM into the Java and .NET environments, as well as greater awareness and understanding, its use has continued to accelerate. There are a variety of key growth drivers, such as mounting dependence on ORM's relevance in fulfilling increasing application demands for functionality that was previously not required or was of lesser importance—for example, reporting, business intelligence, and REST-based data services. Further, as an enabling technology—ORM unique capacities allow smaller, cost-conscious development teams to handily address projects of greater complexity in shorter amounts of time—it is not a stretch to predict that developers will find themselves increasingly relying on ORM as an essential element in their development toolbox. What the next stage of evolution holds for ORM remains an open question, however, there is little doubt that it will further establish itself as an essential element in application development.
Addressing the State of ORM Today
As noted above, ORM has shifted from its origins in large, enterprise-level projects to being more frequently used in applications of varying size and level of sophistication. But for all of the aforementioned shifting and evolution that has taken place, ORM processes, tools, and libraries do not look vastly different than their predecessors. Fortunately, that is starting to change.
Microsoft's game-changing introduction of LINQ to SQL in 2007 set the stage for rapid ORM innovation. Rebelling against years of clunky tools, Microsoft designed a simple, visual tool for ORM configuration, raising the usability bar and opening ORM to the masses. As a result, today there now exist numerous viable and productive third-party options available for developers seeking to include ORM in their coding strategies. Many of these new offerings imitate and expand upon the advances pioneered by Microsoft. Additionally, in this new era of friendlier, easier-to-use ORM, the intimidation factor has been removed: The current generation of ORM tools and libraries offer simpler interfaces and are less onerous to configure than at any other time in the past. This is especially true for non-complex business applications; incorporating ORM has become a relatively straightforward process, making it suitable for nearly all developers and every type of application.
There is one significant area of change that delineates "old school" from today's updated ORM tools: a greater resemblance to their close cousins, productivity tools. Generally, there are two developer classes: developers working on large-scale projects featuring intricate, complex models and vast databases, and those working on less dense, more streamlined applications. In both instances, developers expend great amounts of time and energy creating redundant data access code. By automating various tedious but important refactoring, administration, and enforcement tasks, productivity tools enable developers to focus more attention on the completion of critical objectives. This in turn reduces the amount of hand-coding and overall lines of code required, producing cleaner, and more consistent and accurate code in the end. Similarly, ORM frees developers from having to worry about data-plumbing code so that they can instead concentrate on more critical objectives.
ORM liberates developers from having to pause and consider how their code interacts with the associated database. Because ORM abstracts this away, in essence taking over management of these "behind-the-scenes" tasks, developers can instead dedicate themselves to achieving strategic project objectives and adding value for their customers.
In terms of code reduction, properly leveraged ORM produces significant savings in the lines of code required to build applications, a savings that in some cases, may reach as high as 85 percent. Take data integration coding, for instance: in research done here at Telerik, we've found that in a typical project, data integration coding represents some 50 percent of the total development effort needed. However, this repetitive coding requirement can be constrained by ORM, through the mapping of query result fields to object members. The result is a substantial cut in the lines of code needed to produce the required result.
There are additional long-term advantages to ORM, as well, including the development of a solid foundation of Persistence Ignorance (PI). PI is defined by respected developer and author, Jimmy Nilsson in his book, Applying Domain-Driven Design and Patterns, as "ordinary classes where you focus on the business problem at hand without adding stuff for infrastructure-related reasons….The classes should focus on the business problem at hand. Nothing else should be in the classes in the Domain Model." Over time, ORM intrinsically builds PI into application code by abstracting the business logic from the underlying infrastructure, minimizing the amount of redundant data access code needed and resulting in a code base that is more portable, durable, and easier to maintain.
Although they share some valuable similarities, it is not quite correct—yet—to lump ORM into the same category as productivity tools. However, as ORM continues to evolve and mature, it is possible that its alike-yet-different nature will move it from its standalone position into the greater productivity tool class, benefiting developers at every level.
A Balanced View
Despite all of the inherent benefits it offers, it would be careless to suggest that all is rosy in the world of ORM. There are challenges and complexities that continue to have a mitigating effect on ORM and developers alike, including:
- Bad PR: Among certain segments of the development community, there is a justified bias against ORM that is rooted in its heritage as a hard-to-use, harder-to-configure construct applicable only to large, complex projects.
- Poor performance: Developers often concede that while ORM can be deployed in smaller, more nimble projects, often improving developer productivity, it lacks the horsepower needed to meet the demanding requirements of today's high-volume, high-performance applications.
- It isn't a "one-size-fits-all" solution: Although it may be said that ORM can be applied to projects of every size and scope, there are still instances where ORM is less efficient than hand-coding, which detracts from its value.
These challenges paint ORM in a less-than-positive light, and rightly so. It is true that many developers have been burned by the configuration time ORM used to require, often making it easier to simply write code by hand. A perceived lack of power also continues to contribute to this anti-ORM prejudice, as does the fact that ORM tools can break down in certain instances—trying to do continuous integration builds in Agile environments, for example. Yet even with these detractions, the assertion remains: It is time for a second, more impartial look at the value and benefits of ORM.
Concerns over these challenges and difficulties are justified, as they represent huge time sinks and mountains of frustration for developers. However, ORM vendors are rapidly addressing these shortcomings; ORM configuration and interfaces are being simplified and streamlined. ORM tools and libraries are becoming increasingly sophisticated and more powerful, providing the advanced functionality and robustness needed to fulfill stringent application needs. Many ORM tools are now being built with continuous integration and agile process support out of the box. Developer concerns and complaints have been heard and are being answered. As they say, the only thing that remains the same is change; while it won't happen overnight, change in ORM is indeed taking place.
The ORM of Tomorrow
"Tomorrow can be a wonderful age; our scientists today are opening the doors to achievements that will benefit our children and generations to come… we offer this opportunity for you to participate in adventures that are a living blueprint of our future."
—Walter Elias Disney at the 1955 opening of Disney's "Tomorrowland"
Not to make light of software engineering or ORM, but rather as a genuine tribute to those rare individuals whose unrestricted vision is what propels us forward into tomorrow, it is fitting to open this look at what the future of ORM holds with this paraphrase of Disney's opening-day quote. His dream of creating an inspiring, thought-provoking platform for the next generation of inventors and visionaries has been realized many times over around the world, yet his words from that day still ring true: Breakthroughs and innovations developed today serve as a living blueprint for following generations. The same can be said of ORM today: The ongoing paradigm shift from large to small environments coupled with new advancements and refinements will guide the next generation of ORM tools and libraries, and dictate how they are deployed.
New innovations and developments are driving the evolution of ORM technologies at a rapid pace, changing the face of not just ORM, but the software development process as a whole. While it is impossible to exactly predict what the next generation of ORM tools, libraries, and processes will look like, it is fairly certain that ORM will see:
- Further increases in the level of abstraction between the code and the inner workings of the database, bringing the application's design and functionality closer to the user's intent.
- Continued improvements in usability, GUI, and ease and speed of configuration.
- Inherent transparency resulting from direct, seamless integration into programming environments.
- Better interoperability with developer tools and utilities.
- Elevation of the design process, engendering deeper collaboration between designers, developers, database administrators, and end users.
- Greater relevance, adoption, and deployment.
ORM is presently thought of as an external tool used to supplement the coding environment. However, if recent history is an accurate guide, this will soon no longer be the case. Application development is ripe for a radical transformation. There will be drastic changes in the way developers think about and build software; ORM development is a byproduct of this impending revolution.
As abstraction between application code and the database core grows, developers will no longer be tasked with managing day-to-day relational chores and can refocus efforts on design and functionality improvements that create added value for their organization's customers. Furthermore, ORM maturation and deeper integration with new and existing tools and APIs will turn development into a swift, streamlined process. Constructing applications—of any size and complexity—that have superior architecture and functionality will become easier as design resolves from a hit-or-miss guessing game based on developer supposition of what end users may want into a product resulting from rich collaborative input between all constituencies.
The software development model of the future is about integration, automation, and transparency: intuitive incorporation directly into the programming environment of previously external tools responsible for automating and managing back-end tasks, resulting in substantial productivity gains. As this transformation takes hold, ORM will graduate from being thought of as an appendage; rather, it will be considered an integral component unequivocally integrated into the development environment. Developers will no longer be asking, "Should I be using ORM?" but will instead be asking, "Which ORM should I be using?" And when the reincarnation of application development is complete, ORM as it is today will cease to exist.
Repeatable History: Moving Beyond the 0s and 1s
There are numerous reasons developers should strongly consider implementing ORM as part of their coding architecture—minimized code bloat, improved modularity, increased robustness, and elimination of low-level programming complexities, for example. ORM's rapid evolvement and maturation beyond its early origins as a niche tool have and will continue pushing the art and practice of software development beyond just the 0s and 1s. And as this relentless move triggers new innovations, repeating past triumphs will become the norm rather than the exception, relegating the Law of Repetitive Consequences to nothing more than a footnote in software development's long history of success.
Stephen Forte is the Chief Strategy Officer of Telerik, a leading vendor in .NET components, and a participating board member at numerous technology start-ups. A Microsoft MVP recipient, Stephen is currently the Microsoft Regional Director for the New York metro region and is the co-moderator and founder of the NYC .NET Developer User Group. Stephen has authored several books, including Programming SQL Server 2008, and speaks regularly at industry conferences worldwide. Prior to his position with Telerik, he served as Chief Technology Officer (CTO) for a variety of organizations, including Corzen and Zagat Survey. Stephen is a Certified ScrumMaster and holds an MBA from City University of New York.
