|
[
Permlink
| « Hide
]
Dave Syer added a comment - 20/Aug/07 09:34 AM
I agree that the ItemProvider implementations belong in the infrastructure project. Are you also saying that the DefaultFlatFileItemProvider is redundant, or poorly designed, or would it suffice just to move it?
I would remove the DefaultFlatFileItemProvider as retundand. The wrapper item provider with flat-file input source would make the job.
Another question is the determination of the responsibility of item providers versus the input sources. There is a gray area and it seems the responsibilities are overlapping. Does it make sense to make distinction between these two explicit levels of "input object preparation"? There is a common sequence of tasks for an input component: 1. data acquisition (extracting a data fragment for the particular "record" - i.e. fieldSet for flat file) 2. validating 3. mapping 4. maybe transformation / processing chain The point (1) is currently in the responsibility of input source Points (2) and (3) are a gray area somewhere between input source and item provider. Some technologies enable all 3 tasks do in a single "monolithic" processing, hard to separate. The processing chain (4) could chain more simple processing components (i.e. generate invoice in PostScript format, ZIP the result in the next processing component). This architecture allows huge flexibility and creating a library of simple standard components. You can see the success of such a solution in Unix processing pipes or in Apache Cocoon project. If we go further in this way of thinking - if we have constructed a processing chain - the last component of the chain could write into target space (DB, XML, flat-file, ....). There would come a question if we could omit the "item processor". The answer is probably NOT (?) - because of complex functionality of transaction management, skipping etc. Thanks for the detailed comment. I will probably retire the DefaultFlatFileItemProvider.
I can also see what you mean about gray areas between InputSource/OutputSource and ItemProvider/Processor. The rule of thumb that we worked from was the *Source was low-level, and interacted with external resources, whereas Item* concentrated on the objects. It's a layering of sorts. I will add some detail to the javadocs. Thanks for the detailed comment. I think providing a FieldSetMapper and a Validator is quite a valuable feature of the DefaultFlatFileItemProvider, so I will probably not retire it, but will move it to the infrastructure project. Or do you disagree?
I can also see what you mean about gray areas between InputSource/OutputSource and ItemProvider/Processor. The rule of thumb that we worked from was the *Source was low-level, and interacted with external resources, whereas Item* concentrated on the objects. It's a layering of sorts. I will add some detail to the javadocs. Yes, to move it into the infrastructure is a good solution.
To explain the architecture (maybe with a simple informal diagram with boxes and arrows) and to explain the responsibilities of the particular pieces / components is very helpful (in JavaDoc and later-on also in the reference manual). Also all the other types of input (DB, XML) have to use right names (either "item provider" or "input source" - depending on the responsibility) - to stay consistent with the architecture... But this is a different topic... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Minor
The functionality in "DefaultFlatFileItemProvider" (validating and mapping) should be provided by the infrastructure layer (DefaultFlatFileInputSource).