Yes. I'm imagining something along the lines of Koha::Object, and Koha::Object::Set which would have all the boilerplate we need for general use ( get, set, find, search, etc ). Then all our table-tied objects would inherit from Koha::Object and a set of those objects would inherit from Koha::Object::Set. Both of those classes can be DBIC-aware internally.
Internally Koha::Object would have a DBIC Result as a property, which can be used independently from the database ( which would be good for unit testing ). Each Koha::Object::Set would normally keep only a ResultSet internally and work on that until asked to return a Koha::Object, at which point it would wrap each Result in a Koha::Object and store them internally, or return an array of them depending on what type of return value the method was called with.
I would be willing to write up Koha::Object and Koha::Object::Set if this is what Robin, Tomas et. al. are looking for.
In this way we have DBIC totally encapsulated so the code using Koha::Object and Koha::Object::Set's is totally DBIC unaware but internally is DBIC aware.
In addition, if we have these two classes to inherit from, it will reduce the amount of code we must write, and make it much easier for new developers. One we have Object and Object::Set written, we don't have to rewrite our CRUD boilerplate for each and every new class we add.
What do you think?
Kyle