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

Skip to first unread message

Sanjay Minni

Jan 29, 2023, 5:52:43 AMJan 29
to glorp-group
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 ? 


Esteban Maringolo

Jan 30, 2023, 4:00:22 PMJan 30
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".


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
> To view this discussion on the web visit


Mar 6, 2023, 2:27:39 PMMar 6
to glorp-group

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?

Reply all
Reply to author
0 new messages