0

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

  • 2
    If you do this, have a whitelist of some sort (annotation on methods?) to avoid an arbitrary code execution vulnerability... – Solomonoff's Secret Aug 31 '17 at 18:46
  • only the methods defined in the static map can be used for reflection otherwise I throw an exception (the web-client is actually only a monitoring overview, so entries are added by the application(without reflection) and the web-client can only fetch them through a limited number of exposed methods) – MADforFUNandHappy Aug 31 '17 at 18:50
  • The first answer is about making a Business Layer, but do you have a need for this ? Or is your application about only simple manipulation data ? Considering that you use a map to map url to defined action you shouldn't have any debug problem. Just log properly all information when mapping fail and you're good. – Walfrat Aug 31 '17 at 19:42
  • Yes its simple manipulation but I want to know whats the best practice here – MADforFUNandHappy Aug 31 '17 at 19:44
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.
  • I do some session handling, login handling and some validation in the Servlet and by calling helper classes. The Servlet calls the mapping methods from the DBrouter (the one doing the reflection). Can I use Servlets in combination with helper classes as the BLL ? So it's okay to call the methods of the query beans injected in the Servlet directly (by declaring them public) ? – MADforFUNandHappy Aug 31 '17 at 18:47
  • A Servlet is a class for the presentation layer therefore the servlet should call the BLL, not be a part of it. You should establish a set of classes to be your BLL, and inject these classes into your Servlet. In turn, the query beans should be injected into the BLL and it should call methods on the query beans directly (by declaring them public). Some of the servlet's responsibilities include routing, serialization, deserialization, and authorization. – Samuel Sep 1 '17 at 1:51
  • So let's say I want to send requested entities in a JSON object, the conversion would be part of the BLL and the servlet behaves the same regardless of the data type being requested (JSON, XML...) right? – MADforFUNandHappy Sep 1 '17 at 5:28
  • The conversion to/from JSON to domain objects would happen in the presentation layer (probably the servlet) because it's a presentation layer concern. – Samuel Sep 3 '17 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.