Schema Architecture

[ConvertFromOldNGs]

by Craig Shearer >> Tue, 14 Mar 2000 2:58:19 GMT

Hi

We're about to embark on a new project. I'd be interested in people's thoughts on schema architecture. The current trend in JADE system design seems to be to use the following schema architecture:

RootSchema
{Insert various "base" schemas here}
DomainSchema
CommonApplicationSchema
Application1Schema
Application2Schema
Application3Schema


ie. you have your application's domain classes in a separate schema, then have subschemas for each application.

I can see the advantages of this in theory, but how do people find using this sort of scheme in practise? I would imagine that since JADE can't have a browser open on more than one schema at a time, this would be a real pain to use unless you've been able to completely specify the classes in your DomainSchema fully before starting work on implementing the application.

Comments?

Craig.

[ConvertFromOldNGs]

by Dean Cooper >> Tue, 14 Mar 2000 4:06:56 GMT

In JADE 5.1 you can have browser windows open for multiple schemas at the same time.

Dean.

[ConvertFromOldNGs]

by Craig Shearer >> Tue, 14 Mar 2000 8:02:48 GMT

Great! Presumeably that means I can be modifying stuff in each schema?

Craig.

[ConvertFromOldNGs]

by Dean Cooper >> Tue, 14 Mar 2000 21:47:24 GMT

Great! Presumeably that means I can be modifying stuff in each schema?

Yes.

[ConvertFromOldNGs]

by Robert Barr >> Tue, 14 Mar 2000 20:58:58 GMT

One danger here is to spend a lot of time trying to anticipate future packages and applications that may never materialise. Creating heirarchies of superschemas is fine if you are ABSOLUTELY SURE that App2 and App3 will follow. Unfortunately, the commercial world is sometimes fickle and unpredicatable, and designing code for re-use is EXPENSIVE.

An alternative strategy I've employed successfully is to create the *empty* superschemas as you suggest, but write all the code for App1 entirely in Application1Schema. Should your customer then commission
App2 at a later date, then the re-useable code can be migrated up to CommonApplicationSchema. Sure, there's some difficulties modifying code to be sharable between sub-schemas, but nothing insurmountable (*). This way, the customer incurs the cost of making the code re-usable when they commission App2, instead of a speculative investment for App1, when time to market is often most critical. Similarly with DomainSchema - don't
put any code in here until you have more than one domain to support.
This way, you know the code (and hence the design) you want to re-use is bullet-proof as it's been proved in a working system (in the
sub-schema). When you come to write App2, there are minimal bugs in the re-use code, so there's little no need to move back and forward between schemas in the development environment.

(*) Retrospective insertion of superclasses (and especially superclasses of forms) is difficult, so create any superclass definitions that you
can anticipate as empty classes in the superschema when building App1. Leave these empty and add attributes, references and methods in Application1Schema - these can easily be 'moved up' to a higher schema before building App2 in a single pass using partial extract/load - then you can provide specific execution for App1, App2 etc. using overrides.

[ConvertFromOldNGs]

by Peter Gallagher >> Fri, 24 Mar 2000 0:41:18 GMT

The below comments are interesting. We have found the exact opposite.

In fact,
1. Jade makes Re-use very inexpensive

2. By designing our code for re-use we have improved our general approach to writing applications in Jade, to the extent that if the application we are writing is completely new, we already have a range of re-useable components and methodology that makes starting so much easier. And I would add the methodology is more important than the reused components/code.

3. Yes the real world is fickle, however to not plan for a common approach would mean that every development has to start with "designing the wheel"

4. Craig, your schema structure that you are proposing to use is similar to the structure we have been working with for 18 months. I can tell you it works, its robust, and it saves development time (especially later) - Is it a pain to code in two or more schemas? - well yes, however see previous response.

5. I would recommend that you try to push as many things up the schema structure as possible (depending on its purpose/nature etc). The sooner you do this the sooner the time savings accrue. Shifting components up the schema structure is more difficult then putting the bits up there first(yes we know about partial schema loads etc - end result - still difficult). If you are unsure how a particular component might work/perform and believe that it will reside in a higher schema, then create the bones of the component in the higher level and then sub-class/inherit at the lower level - building the specific code at this lower level and testing how it will work.

6 Are there tricks to make this multi-schema inheritance/subclassing work with ease - YES, are we going to tell you NO

Good hunting...

Peter Gallagher