[Koha-devel] Koha and DBIC

[Kyle Hall]

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 <M.de.Rooy at rijksmuseum.nl>
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
> Koha-devel at lists.koha-community.org
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20140916/27e01607/attachment-0001.html>