methods #classModel & #descriptorFor in DescriptorSystem or in the Domain Class side

[Sanjay Minni]

I have some queries around good practices - the background is that a large business app will have several modules with overlapping domain classes, for example a PurchaseSystem, a SalesSystem ... and each of these may use some common classes from the AccountingSystem. The discussion points are: 

A. Are separate AppDescriptorSubSystems advisable instead of 1 large AppDescriptorSystem ? 

There may be some code duplication in separate AppDescriptorSubSystems, while a large AppDescriptorSystem can be confusing and lead to exposing a lot of system to various teams. This system could have 100+ Domain objects and Tables each between 10 logical subsystems. 

 B. Instead of having the methods #classModelFor... and the #descriptorFor... in the AppsDescriptorSubSystem, is it a better alternative to have these as class methods #glorpSetupClassModel:forSystem: and #glorpSetupDescriptor:forSystem: within each of the Domain Class? 

This will avoid duplication across AppDescriptorSubSystems when these classes are reused, while also putting the code alongwith the Domain class what are the pitfalls ? 

thanks

Sanjay

[Esteban Maringolo]

What I did was to use Traits to define the different systems for the
different applications, using them as modules.

However I was not very comfortable with Traits (it was the
first generation of Traits), so I started "prototyping" a Descriptor
system that didn't rely on the selectors to resolve class models,
descriptors, and tables, and instead was more declarative (and
delegated to the classes as a last resort to "install" themselves into
a Descriptor System), but that got abandoned and now I have no reason
to build it that way (although I'd like to have it that way).

So... answering your question, you subclass DescriptorSystem to
resolve things the way you prefer, or you also subclass
DescriptorSystem and install different traits for the different
applications you have.

There is a cost in the setup of a DescriptorSystem if it contains a
lot of models and descriptors, because it validates them when starting
them up, that was something I also did optimize back then, having a
"lazy validation" for regular use, and a full validation to work only
as a "type checking mechanism".

Regards,

Esteban A. Maringolo

> --
> You received this message because you are subscribed to the Google Groups "glorp-group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to glorp-group...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/7ac3f962-6327-4de1-930b-cf06765f4a28n%40googlegroups.com.

[jtuchel]

Sanjay,

it seems we're quite alone with Glorp ;-) I really wonder if there are no RDBMS users in the Smalltalk world who are not stuck on some ancient Persistence framework (TOPLink, Mikado, POLAR ...)...

I have never tried anything else than the classic #classModelFor... and the #descriptorFor.. methods in one single descriptor system, so I can't really tell.

Did you make any progress on your ideas? Any insights you can share?

Joachim

[jtuchel]

Sanjay,

maybe I am a bit late here, but I was just re-reading your question and thought maybe I'd try to introduce a descriptor per subsystem? Not sure I understand the implications down to the bottom, but it sounds like there must be some place where a subsystem knows which other subsytems it's using and you could probably construct your descriptor system by letting each subsystem contribute "its" classModel/descriptor/table methods to the actual DescriptorSystem instance?

Joachim