OS: One large library or many little ones?
pmulroney at logicaldevelopments.com.au
Mon Aug 30 01:06:13 UTC 2021
We did the same as Andy. When we moved from O7 to Studio, we realised that we had developed the same contacts system several times over, and each one was slightly different. By merging the contact-specific features of each system into the one "contacts" library, we could deploy that to everyone. The upside is that fix the bug for one client -> fixes it for everyone. So we separated our monolithic libraries into separate libraries, one for each function/task/category.
Just like Andy, we created a "Broker" library that would load the individual libraries and manage dependancies etc (eg Library X requires library Y etc), and also has a priority system where a library could request a particular class, and if the custom library advertised that it had that class, then the custom class was used instead of the default one. It's a powerful system, which allows for a large degree of customisation over the standard functionality.
We have modules for administration like contacts, appointment book, etc; accounting modules like cash and accrual, invoicing, receivables, payables etc; industry-specific modules for transport, scrap metal, manufacturing. This gives us a solid core for any new system - a combination of existing modules plus any customer-specific options to build a system rapidly.
It's a bit of effort to get the structure in place, but the benefits are enormous. Well worth it!
> On 30 Aug 2021, at 8:46 am, Andy Hilton <andyh at totallybrilliant.com> wrote:
> FWIW when I was contemplating these exact questions many moons ago, I opted for principally one main app (made up of many individual libraries really to make it easier for me to understand) - and then I add separate ‘client’ libraries on a per client basis…..
> What I do is to have some principal generic code that, for each component required, looks to see :
> a) do I have a ‘client library’ installed ?
> b) If I do, do I have the required component in that library ?
> c) if found, use the client version
> d) if not found then use try default (generic) component
> This has allowed me to create both highly customizable as well as easy default setups and maintain my code base over many years…….
> For comparison, I have around 200 database tables in total, and run 9 ‘application’ libraries, and 4 ’system’ libraries and assorted custom client libraries as required
> It took a while to evolve but I am very comfortable with it and find it pretty easy to maintain and continue to develop….
> Best design decision I ever made to break it up into smaller modules……
> Happy to share more if needed…..
> Andy Hilton
> Totally Brilliant Software Inc
> Phone (US) : (863) 409 4870
> Phone (UK) : 0207 193 8582
> Web : www.totallybrilliant.com <http://www.totallybrilliant.com/>
> Helpdesk : http://totallybrilliant.kayako.com
> Email : andyh at totallybrilliant.com
>> On Aug 29, 2021, at 8:28 PM, Jim Creak <jim at jacsoft.co.nz> wrote:
>> Hi All,
>> Still stuck in Classic, would like to move out, and have a few people helping me with that :)
>> One of the questions I have been pondering, and can see benefits and disadvantages from each is the idea to either build everything into one large library, or build each module into it’s own library.
>> I have two main programs that I maintain, plus a few smaller clients, so another question would be do I develop just one super app for everyone, which would mean lots of helpful shared code to speed it all up, or leave them separate from each other and try to manage the shared code some other way.
>> Peoples thoughts?
>> JACSoft Programming Ltd. <http://www.jacsoft.co.nz/main.shtml>
>> Manage your list subscriptions at http://lists.omnis-dev.com
>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
I hate Russian dolls, they're so full of themselves.
Paul W. Mulroney We Don't Do Simple Pty Ltd
pmulroney at logicaldevelopments.com.au Trading as Logical Developments
www.logicaldevelopments.com.au ACN 161 009 374
Ph: +61 8 9458 3889 86 Coolgardie Street
BENTLEY WA 6102
More information about the omnisdev-en