[Koha-devel] Restructuring C4

[Ian Walls]

I also would like the separation of business logic from data access.  I'm
seeing several tiers in the structure:

Template
Script
Business Logic library
Data Access library
Data structure

We can then have multiple templates to meet the needs of the library.  Bonus
points for making it fully customizable in by the librarians.

For third party integration, like SIP2 or NCIP, we would probably need
separate script level from the normal routines.  This wouldn't be a problem
if core functions were abstracted into the Business Logic library level.
That level would in turn call the data access level, which we could set up
to handle multiple backends (MySQL, Postgres, etc)


Separately, in addition to only exporting the functions needed, what about
moving the "require C4::whatever;" lines out of the BEGIN{} block and into
the subroutine that needs use of whatever's functions?  Right now, we load
all the modules at the beginning, even if only a single subroutine makes use
of that module.  If the script that uses the module only exports a single
function, and it's not the subroutine that's being used, lots of time is
wasted loading extraneous code.

For example, in my profile of circ/circulation.pl, I found that C4::Budgets,
C4::Category, C4::ClassSource, C4::Heading, C4::Heading::MARC21,
C4::ItemType, C4::Message, C4::Print, C4::Search, C4::Search::PazPar2,
C4::Serials, C4::SMS, C4::SQLHelper, C4::Suggestions, C4::VirtualShelves and
C4::XSLT were all loaded, but none of their subroutines used.  This may only
save a few microseconds, but perhaps the simplification would help.

Cheers,



-Ian

On Wed, Apr 6, 2011 at 8:30 AM, Galen Charlton <gmcharlt at gmail.com> wrote:

> Hi,
>
> On Wed, Apr 6, 2011 at 12:11 AM, Robin Sheat <robin at catalyst.net.nz>
> wrote:
> > Additionally, do we want to split things up within the Koha namespace,
> > for example database-accessing code vs. the more business logicy stuff?
> > My personal inclination is to not do that, and it wouldn't be a terrible
> > refactoring to do at a later stage if it were required.
>
> I'd prefer a separation between business logic and data access,
> actually.  Perhaps
>
> # data access - though the choice of naming may better follow whatever
> pattern DBIx::Class imposes:
> Koha::DB::biblio
> Koha::DB::accounts
>
> # business logic
> Koha::Acounts
> Koha::Cataloging
> Koha::Cataloging::Biblio
>
> or the like.  Obviously we could debate the hierarchy ad infinitum,
> but as long as names are well-chosen and we don't lump unrelated
> things together, we can run with what works.
>
> > Oh, something else that's recommended that I tend to do is not export
> > anything by default, requiring the module to be included like:
> >  use C4::Accounts qw/ get_users_balance /;
> > mostly this prevents surprising things getting into your namespace. This
> > is more a style suggestion though.
>
> I agree with Colin that this should be more than just a style
> suggestion.  We shouldn't include more than the bare minimum in
> @EXPORT; @EXPORT_OK is to be preferred.
>
> Even better would be an object oriented design.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> gmcharlt at gmail.com
>



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
ALA Booth 732
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110406/f347124c/attachment.htm>