\o/ If I understood correctly, it's exactly what I had in mind, so I totally agree!
2014-09-16 13:16 GMT+02:00 Kyle Hall <[email protected]>: > 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 > > http://www.kylehall.info > ByWater Solutions ( http://bywatersolutions.com ) > Meadville Public Library ( http://www.meadvillelibrary.org ) > Crawford County Federated Library System ( http://www.ccfls.org ) > Mill Run Technology Solutions ( http://millruntech.com ) > > On Mon, Sep 15, 2014 at 3:11 PM, Marcel de Rooy <[email protected]> > wrote: >> >> > I am troubled by the idea that we should wrap all our dbic classes in >> > yet more classes. Every example I've seen of this has more code by a factor >> > of almost 10. I don't know if Koha is so complex that it requires a >> > repository pattern. >> I think that it would require rewriting Koha. This changeover might just >> be too complex for us. >> >> > How much more difficult will this be for developers, and how much more >> > overhead will it require if we wrap our objects in more objects? We'd have >> > to fetch the Row objects, wrap them in KohaRow objects, wrap those in a >> > KohaRowSet, and return them. Certainly, but far more complicated. >> I would say: Leave all storage related actions in Koha::Schema. KohaRow >> does not make sense to me. >> Furthermore, define the objects that actually have 'real' business logic >> and put that in some Koha::Object. >> >> Marcel >> >> _______________________________________________ >> Koha-devel mailing list >> [email protected] >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ > > > > _______________________________________________ > Koha-devel mailing list > [email protected] > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
