When the solution hides the problem.

A comment on How to Create Your Own 'Dynamic' Bean Definitions in Spring:

The solution hides the problem. I enjoyed reading about the details of the insides of Spring, but the solution was too complicated for the problem. A real value of Spring is that generally it does not get in the way of straightforward solutions. The problem here, picking a datasource based on key could have been handled with a simple DataSource delegate that can pick the actual datasource from an injected mapping of key to datasource. The management of the mapping would be done elsewhere -- JMX, webapp, etc.

For me, the red flag would have been when I thought the solution required a weekend of prototyping to understand the internals of Spring.

This is off topic, but related to picking solutions. You also need to think about the person maintaining your solution. A complex solution will require that the maintainer be at least as talented as you and that can be an unnecessary burden on the organization.

No comments: