Do my Service objects really belong in an entity package?

I've noticed where I work, that we have a tendency to put our Service level objects into our entity package. This made me wonder if my concept of an entity class was wrong. I though entity classes represented a table in a relational database, am I correct? If so, where would you recomend putting these objects, pe开发者_开发知识库rhaps in a Service objects package?

I logically separate them based on their concern. The point of even having a Data Access layer, Service layer, etc. is separation of concerns. I tend to go a little over board, but I do something similar to:

app
--model
----PersonEntity.java (JPA annotated entity)
--service
----PersonService.java (interface)
--web
----PersonController.java (SpringMVC Controller, Struts action, etc.)
--internal
----PersonServiceImpl.java (Contains JPA EntityManager, e.g.)

That is, if you intend to keep everything in the same project. I would probably separate the service and model code into it's own project, in case (for example), you might write a separate web service and reuse the same domain model.

FYI, I'm not a fan of DAOs, but they're pretty prevalent. I'm not sure where I would put a dao, but I'd probably follow the same convention. An extra package is just another folder, it's no biggie, and makes sense to organize your code as much as possible.

Where I'm at, we define the entity object in a package within a module. Then, the service interface will be in the same package, in the same module, but the implementation will be in the same package in a different module. It can be nice to keep all the code related to EntityX within the same package; that includes the Entity, Dao, and Service definitions and implementations.