views:

105

answers:

2

I've got a set of classes, namely, a data transfer object, a service implementation object, and a data access object. I currently have business logic in the service implementation object; it uses the dao to get data to populate the dto that is shipped back to the client/gui code.

The issue is that I can't create a lightweight junit test of the service implementation object(it's a servlet); I think the business logic should be elsewhere, but the only thing I can think of is putting business logic in the dao or in yet another layer that goes between the dao and the service implementation.

Are there other options, or am I thinking about this the wrong way?

It's a GWT/App Engine project.

+1  A: 

I don't understand why you can't unit-test the servlet, e.g. as per this SO question (there are others on similar themes) -- can you please explain?

Edit: if there's no special reason, I suggest you should the business logic in the service layer (where it seems to belong) and unit-test it there -- the approaches suggested in the SO question I just quoted, for example, seem reasonably lightweight (though I didn't test them specifically).

Alex Martelli
other then ignorance, no reason. thanks.
antony.trupe
OK, then I think you should keep the business logic in the service layer and unit-test it there -- the approaches suggested in the SO question I quoted seem lightweight enough (though I didn't test them specifically).
Alex Martelli
A: 

You can put your business logic in it's own jar file and test this component independently from the integration with the web (servlet)

The servlet is just a protocol, it is not your business logic, more an integration point.

It must be easy to imagine to expose your same business logic through a thick client. Also in that case, you should not hide the business logic under buttons or links.

One more note: you might want to look into the MVC framework; struts. Your model will hold the business logic.

Hope this helps.

Sentient