[Koha-devel] Koha and DBIC

[Jonathan Druart]

\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 <kyle.m.hall at gmail.com>:
> 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/
>
>
>
> _______________________________________________
> 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/