David E Jones wrote: > 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.
The refactoring I mentioned never talked about implementation of the common services; they could very well still be simple methods. > 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. Exactly the point I'm trying to make. If every CRUD implementation on every entity has it's own implementation, then there are that many *more* things that have to be learned. However, if you see that entity #1 uses one implementation, then entity #2 uses it, and entity #3 uses it, ..., then that's *less* that you have to learn. It should *always* be possible to have per-entity implementations; no one is suggesting that that feature be removed. But reducing code, by refactoring, and reducing the learning requirements, *is* a win. Commonality is *good*. If it weren't, we wouldn't have an entity engine, or a service engine. We'd have hard-coded jdbc calls and bsf usage scattered all over. If just 2 entities share the same CRUD implementation, then we have reduced the knowledge workload, and that is a win. > 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. Please stop making my points for me.
