Dave Rolsky writes: > Trying to jam a thick layer of OO-goodness over relational data is asking > for a mess.
Most OLTP applications share a lot in common. The user inputs data in forms. The fields they edit often correspond one-to-one with database fields, and certainly their types. The user wants reports which are usually closely mapped to a table/view/join, i.e. an ordered list of tuples. A reasonable O/R mapping can solve this problem easily. Like Perl, it makes the easy things easy and the hard things possible. The bOP Pet Shop demostrates how you can build a simple application with only a couple of custom SQL queries. The rest are simple joins and CRUD. If you need more complex queries, there are escapes. You still probably end up with a list of tuples for your reports. The key we have found is avoiding indirection by naming fields and models the same in SQL and Perl objects. This allows you to seamlessly switch between the two. We've found the O/R mapping to be an indispensable part of the system. Since all data is contained in objects, the views/widgets don't need to how the data is populated. They access all data through a single interface. Rob
