why are static finders bad?

[ccavallieri]

Hi all,

in an old post I was struck by this sentence

I'm not comfortable with is the fact that finders are generated as static methods. There are lots of good reasons why developers have moved away from statics to container managed singletons

could someone explain me wich are these good reason? Are static methods "danger" if used also for updates or inserts?

[Brad Murray]

Its a bit of a question of how they should be tested I think

Its convenient, and leads to quite clean code if you have a static finder method, but you lose the ability to insert a test seam between the domain object and the database.

If you prefer to add mock results for everything coming back from the db, then this is probably not a style that you would be happy with.

Personally for domain object tests, I prefer to have my test populate the data itself (rather than use Roo DataOnDemand classes), persist, and then check the results of finders etc. This also means that any validation issues come to light quickly. It does mean that these are short integration tests rather than true unit tests, but running against a clean in-memory database they execute fast, and its a little difficult to truly unit test a spring/hibernate/jpa domain layer without mocking so much of the frameworks that your tests stop telling you anything useful.

In most cases your static finders are only executing automagic JPA generated queries, or custom HQL, so there isn't a lot of business logic to test anyway.

[ccavallieri]

thanks for your response,

if the problem is only "test releted" i'm not afraid, my fear was that this could also generate problem on concurrent updates ...

for example, is correct in roo create a static method that, given a parameter (an item code for example) execute a search and then loop over the result and do an update on each item found? can this generate any problem?

[jlic]

As long as you mark the method with @Transactional, u shouldn't have any problem with concurrent updates. The maven build and Spring config (applicationContext.xml) that comes preconfigure with Roo already have Spring transaction properly configured.