Information and Software Technology 82 (2017) 1–18 Contents lists available at ScienceDirect Information and Software Technology journal homepage: www.elsevier.com/locate/infsof Twenty years of object-relational mapping: A survey on patterns, solutions, and their implications on application design Alexandre Torres a,* , Renata Galante a , Marcelo S. Pimenta a , Alexandre Jonatan B. Martins b a Instituto de Informática - Universidade Federal do Rio Grande do Sul (UFRGS), Av. Bento Gonçalves, 9500, Porto Alegre, RS, 91501-970, Brazil b TAGMATEC, Rodovia SC-401, 600, ParqTEC Alfa, CE Alfama, sala 405, Florianópolis, SC 88030-911, Brazil a r t i c l e i n f o Article history: Received 30 December 2015 Revised 23 September 2016 Accepted 27 September 2016 Available online 28 September 2016 Keywords: Object-relational mapping Design patterns Impedance mismatch problem Enterprise patterns Class models a b s t r a c t Context: Almost twenty years after the first release of TopLink for Java, Object-Relational Mapping Solu- tions (ORMSs) are available at every popular development platform, providing useful tools for develop- ers to deal with the impedance mismatch problem. However, no matter how ubiquitous these solutions are, this essential problem remains as challenging as ever. Different solutions, each with a particular vocabulary, are difficult to learn, and make the impedance problem looks deceptively simpler than it really is. Objective: The objective of this paper is to identify, discuss, and organize the knowledge concerning ORMSs, helping designers towards making better informed decisions about designing and implementing their models, focusing at the static view of persistence mapping. Method: This paper presents a survey with nine ORMSs, selected from the top ten development platforms in popularity. Each ORMS was assessed, by documentation review and experience, in relation to architec- tural and structural patterns, selected from literature, and its characteristics and implementation options, including platform specific particularities. Results: We found out that all studied ORMSs followed architectural and structural patterns in the liter- ature, but often with distinct nomenclature, and some singularities. Many decisions, depending on how patterns are implemented and configured, affect how class models should be adapted, in order to create practical mappings to the database. Conclusion: This survey identified what structural patterns each ORMS followed, highlighting major struc- tural decisions a designer must take, and its consequences, in order to turn analysis models into object oriented systems. It also offers a pattern based set of characteristics that developers can use as a baseline to make their own assessments of ORMSs. © 2016 Elsevier B.V. All rights reserved. 1. Introduction Relational Databases (RDBs) and Object-Oriented Programming Languages (OOPLs) are based upon distinct paradigms, containing technical, conceptual, and cultural incompatibilities. The obstacles of dealing with such incompatibilities are commonly referred to as the object-relational Impedance Mismatch Problem (IMP) [1–3]. If system analysis aims at the recognition of the business prob- lems, sketching platform independent solutions, such as identifying and applying analysis patterns [4], the design activity is focused in fitting the analysis to the limitations of the chosen platform. At the * Corresponding author. E-mail address: atorres@inf.ufrgs.br (A. Torres). design, the IMP can turn analysis models into something difficult to understand, maintain, evolve, and even track back to the original idea. For example, two basic concepts on OO models are inheritance and many-to-many relationships, both extensively used on analysis models, such as analysis patterns [4], and both are absent on RDBs. Primary and foreign keys are important concepts for good database design, and both are absent on OOPLs. Bridging these conceptual mismatches, without losing the tracking among all artifacts, is the challenge of the IMP. In many projects it is possible to avoid the IMP, by not ad- hering to Object-Oriented (OO) practices, or not using a RDB. Sometimes it is feasible to place all domain logic within stored procedures. Another way is using NoSQL persistence, such as Document-Oriented Databases, and deal with other kind of mis- http://dx.doi.org/10.1016/j.infsof.2016.09.009 0950-5849/© 2016 Elsevier B.V. All rights reserved.