The EOModeler Adavantage ? / Time to refactoring job ?/ WOF longevity/success becomes a nightmare :-)
The EOModeler Adavantage ? / Time to refactoring job ?/ WOF longevity/success becomes a nightmare :-)
- Subject: The EOModeler Adavantage ? / Time to refactoring job ?/ WOF longevity/success becomes a nightmare :-)
- From: Stephane Guyot <email@hidden>
- Date: Sat, 29 Oct 2005 10:41:06 +0200
Hi list,
after almost 10 years of WebObjects/EOF , we starts with WOF1.0 and persistent, transient variables in WOComponents ... :-)
today we just have these statistics :
Number od Models : .............................................. 43
Number of entites : ................................................578
Number of attributes : ....................................... .5265
Number of relationships : ......................................995
Number of named fetch specification : ...............553
I hope my WOD statistics are goods (?) :
countModels : WOString {
value = models.count;
}
sumEntities : WOString {
value =email@hidden;
}
sumAttributes : WOString {
value =email@hiddenemail@hidden;
}
sumRelationships : WOString {
value =email@hiddenemail@hidden;
}
sumFetchSpecificationNames : WOString {
value =email@hiddenemail@hidden;
}
We have many applications but most of them doesn't use all the entities, and i'm currently looking for how to determine, to define a way to load only required models and entities. We have custom way to load all models and EOs in sharedEditingContext but it's not very fine grained, to do that we loads all entities and dynamically adjusts from properties files, it's perhaps very bad idea.
How you handle packaging of classes and models ?
For historical reasons we puts all the models in one subproj, because Project Builder/EOModeler doesn't like so much inter models relationships in differents projects. Does Xcode in 5.3 do a better jobs ? ( No more stupids , Clear Destination Entity, I will Find it , questions ? )
Perhaps it's time to write a custom EOModelGroup ?
In one models we have 137 entities, and 137 classes , but in fact it's just single table mapping, we only have one "intelligent" class, and 136 stupids classes, that only have special Type ( it's a kind of intelligence , but it's still lot of noise ).
In another models we have all the business logic of the hierachical Business Units, but in fact we have dedicated WO instances restricted to specials Businness Units. and don't have restriction o each instance. What is the better solution, share th code, share the model and dynamically adjusts with restricting qualifiers at run-time ?
Is there a smart way to handle such situations ?
995 relationships implied some complexity in the graph of objects (:-()), how do you handle such "spaghetti situation" ?
For the moment i'm just begining to investigate and do nothing except asking myself questions and tests... (EOClassDescriptionNeeded ?)
but any suggestions, experiences are wellcome.
Stephane
PS : OK, small is beautifull , but the reality becomes a nightmare :-)
EOModeler is very buggy but we are not with Hibernate and the by hand doing made .hbm.xml configuration files ;-)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden