Reflecting on Reflection
I was approached by a developer suggesting a reflection routine for taking values from a data transfer object and populating a business entity and vice versa. He argued that writing a TransferObjectAssembler for each DTO was too time consuming, and would be better suited with a reflection routine. My response was no, not a good practice. But why? It seemed clean enough. It was fairly straight forward code for the particular implementation scenario he was looking at. So, why not? It would certainly save a few million lines of code. But what are we really saving? And at what cost? It's no secret--reflection is slooooowwwww. At least in comparison to explicit design-time coding. Case in point: I helped out with a code review of a similar implementation where reflection was being used to create a generic routine to "convert" DTOs to business entities and vice-versa. While the DTOs were quite large, they were not ridiculously complex, and very typical of the particul...