Writing Your Own Mapping Layer
It can be very tempting to write your own object-relational mapping. If fact, there are books and articles advocating this. The bottom line, however, is that unless you have a very simple mapping, it is a bad idea to write your own mapping layer.
I have talked with plenty of developers who tried writing a mapping layer. The result, although anecdotal, is universal. The mapping code, in each case, grew to be 30 to 40 percent of the code needed for the entire application. There are two problems that resulted from this. The first is that this is a lot of effort towards writing code that is not addressing the business problem that prompted the application development in the first place. The second is that, given the development models that show how code defects rise with total code, a significant number of additional defects appeared which, again, are not directly related to the business problem being addressed by the application development.
So, if you have a relational database and you want to use C++ or Java, by all means use an object-relational product. Writing a mapping layer is much harder than you might expect. Some of the reasons this is hard can be seen in the considerations for mapping:
- For object-to-table mapping, see mapping objects to tables .
- For table-to-object mapping, see mapping tables to objects.
Context for Writing Your Own Mapping Layer
Related Articles for Writing Your Own Mapping Layer
Author
Douglas K Barry
Principal
Barry & Associates, Inc.
The Savvy Manager's Guide
Douglas K Barry is also the author of a book that explains Web Services, service-oriented architecture, and Cloud Computing in an easy-to-understand, non-technical manner.
Web Services, Service-Oriented Architectures, and Cloud Computing: The Savvy Manager's Guide (Second Edition)
by Douglas K Barry with David Dick
This is a guide for the savvy manager who wants to capitalize on the wave of change that is occurring with Web Services, service-oriented architecture, and—more recently—Cloud Computing. The changes wrought by these technologies will require both a basic grasp of the technologies and an effective way to deal with how these changes will affect the people who build and use the systems in our organizations. This book covers both issues. Managers at all levels of all organizations must be aware of both the changes that we are now seeing and ways to deal with issues created by those changes.