I see the point, thanks for comment David Jacques
De : "David E Jones" <[EMAIL PROTECTED]> > > On Oct 16, 2007, at 12:51 PM, Jacques Le Roux wrote: > > > De : "Adam Heath" <[EMAIL PROTECTED]> > > > >> Another point; in lots of simple method definitions, there are blocks > >> for doing CRUD to entities; in the vast majority of cases, these > >> method > >> definitions are *identical*, except for the entity name and > >> property to > >> pull error messages from. This points to a need to refactor. > > > > IMHO, this point is very interesting, but of course need some work... > > These were designed VERY specifically to be this way. It is true > there are only a few common variations for different data structures > and corresponding create/updated/delete operations. > > The point of having simple-methods exist for this instead of just > have "call create variation A" in the service definition is to make > it easy to customize and enhance. As functionality around certain > entities grows these methods do tend to grow beyond the base 2-4 > operations that the typical minimal methods include. > > So, yeah, it was intentional to have separate operations for things > like (all of these are just for creates, different combinations for > different things): > > 1. make a value object > 2. put a sequenced id in a single pk field for the object > 3. move all primary key fields from the parameters or other Map into > the value > 4. move non-pk fields from a Map into the value > 5. set individual fields on the value > 6. and so on... > > We could identify a few variations and have single operations, or > avoid writing simple-methods altogether with the service def thing I > mentioned above, but that would just reduce consistency between > different simple-methods and make customization and extension more > difficult. > > It seems like some recent comments stem from a disagreement that > consistency and ease of customization are important... that might be > an interesting thing to talk about explicitly. Much of the OFBiz > framework is meant for help just those things, where necessary > sacrificing other priorities, all part of optimizing the development > experience at the XML file level. > > The driving factor behind that priority is that in most large > software it is complexity that kills projects and causes budgets to > spiral out of control. As complexity increases the time and cost > tends to increase in a non-linear way, ie something like > exponentially or logarithmically instead of linearly. When I say > complexity I mean general solution complexity across hundreds of > entities and services and screens, and not the complexity of a single > service. The point of defining the scope and purpose of a service is > to limit the complexity of that one piece to make it possible to > write and maintain it with a reasonable volume of requirements. > > For OFBiz (both the framework and the applications) it is critical > that we all keep this in mind. It does us no good to create something > that supports super fast development if it makes ongoing maintenance > and extension/customization more difficult (including other people's > code or years later when you've forgotten and it might as well be > something someone else wrote). The point is to be as clear and > consistent as possible across a variety of data structures and > business processes. > > When talking about framework improvements that should be the first > thing considered and written about when presenting ideas. Ideas that > don't help with that will be fought pretty hard by various people, me > being the most vocal, but rest assured that if I shut up others will > fill in because lots of people in the ofbiz community have experience > with this and know what kind of a difference it makes. > > -David > >
