Well I know there are already a lot of questions about this topic. But I'm still very feeeling very insecure. Sorry for my bad english!
So I'm working as software developer for about two years now. In the first company I worked, we never used Reflections. We had a lot of boikerplate code, services, controller for every entity. It wasn't bad, but often there were small variation between the controllers and services. That took a lot of time to be sure, every class conform the given pattern.
In the actual company I'm working, we use Reflections in all core components. We deleted about 110'000 lines of code (15% of the whole project) in our persistence layer because of reflections. We have about 200 Entities, all are handled in one entity procesor handling all relations, persisting and so on. I was excited about Reflections! So much boilerplate code we can remove. It makes editing Entities or other adjustments so easy.
Now I'm working on my own project. During looking for best practices I read so much about how bad (for performance) and risky the use of Reflections is. This make me very insecure about using Reflections. I read things like "in 99,99% of the cases, dont use Reflections" or "I would say almost 100%". Actually I can't understand why ... I mean with Reflections you can remove so much boilerplate and be sure, the code is handled the same way for each Class. I mean writing persisting services for many entitites, creates so much space for possible errors or small differences. Is it realy not recommended to use Reflection for things like entities, which are following a defined pattern, which nearly never changes? I mean yes, you have to be careful with possible errors and so on. But when I wrote the code, it works amazingly good!
In which cases is it worth to use Reflections over tons of boilerplate code?
Thank you for your answers :) Teach me!
Aucun commentaire:
Enregistrer un commentaire