Is using Java reflection to map frontend actions to the actual db methods by name bad practice?

Question

I have used java reflection with a static map to map actions(removeElements, getLatest ...) from the front end to the corresponding database methods by name in multiple web applications now.

I was wondering if this use for reflection is considered bad practice ? (I read that reflection causes hard to find bugs)

If it is what should I do instead ? (I want a Single way of accessing the DB query beans and the front end should not know the real method names)

Conclusions:

So to map requests from the front end to the db I see these alternatives to reflection:

• REST (action defined by http method)

• hell lot of switch/case if/else -> but this I would consider worse
  than reflection

Answer 1

I would recommend you establish a business logic layer (BLL). The business logic layer is called by the presentation layer to perform the actual work of the application. This includes things like:

• Validation
• Database access (through collaboration with your query beans) which may be more complex than a single call.
• Conditional logic
• Caching

This layer should basically read like your system requirements, and you should be careful not to put all this logic in your query beans. It is appropriate for the front-end to call the BLL directly through method calls. If this is a backend accessed by a web client, you should probably create a REST interface over the BLL. Essentially every front-end or presentation layer must go through the BLL. This makes your application consistent. While your application may currently be a simple one-to-one mapping that a reflection solution may be able to solve, it's almost guaranteed that your requirements will change and become too complex to represent in the database schema and data access module.

Besides establishing an intermediate layer between your presentation layer and data access, I would recommend against using reflection whenever possible. You can read about the downsides of using reflection on almost any reflection question, but here are a few issues with it:

• Largely inflexible - when you attempt to create a reflection-based solution, you're generalizing the solution (which is good), but often the limitations, requirements, and goals of the solution are hidden. Generalization can be achieved through polymorphism instead. For example if you have the system you describe, but now you need to pass arguments, how do you invoke the methods through reflection, generically, and to support any number and any type of arguments? More difficult to control instantiation and scope of the query bean.
• Eliminates compile-time checking. You cannot guarantee that the frontend will work with the backend at compile time. You must write extensive integration tests to make sure that there aren't typo's or misconfigurations in your system. Even then, your production configuration may be misconfigured and not caught by tests.
• More difficult to follow. You cannot trace usages of your methods in the system with the IDE, instead you must rely on file search to find configured invocations of your methods.