This discussion is related to something I have been after for some while. A while back I searched many groups but couldn't find anything.
I think it would be great to come up with a default package structure that is a bit of a recommended practices for what types of classes go where and what they should do, something in the order of a maven standard directory layout but for packages. I have pulled down various sample code from different projects and tried to come up with something from that. Clearly there may be different "templates" for small versus large projects, diff reqts etc. but i'd find it very useful. For example:
NB: [namespace] = (e.g. com.company.project.[subproject])
NB: This is just an example and i'm def Not saying this is correct. Just wondering if anyone knows of something like this or has an interest in constructing one.
NB: All packages contain interfaces. If separate dirs for implementations, then subdirectory of 'impl'. If not separate dir interfaces + impls directly in package.
- [namespace].service = service classes which includes stateless services, managers, etc. ideally not static so that they can be easily be stubbed.
Service classes may contain collections/caches to be able to track the model objects upon which they are working, but if so they should be thread safe if in a multi-threaded env (more and more common these days)
- [namespace].model = stateful domain classes. "managed"/operated upon by the service classes. often not beans but if so must be prototype and instantiation managed
- [namespace].dao = db abstraction. Here I'd like to detail suggestions - like for non-ORM recommended SimpleJdbcTemplate, declarative txn mgmt, etc...), for ORM.. blah blah. typically injected into services.
NOTE: I use 'service' generically to indicate stateless classes that provide a service and likely take return a result or potentially act upon the object passed in. To me this includes 'Services' and 'Managers' and things like 'Calculators' or anything that fits that description of acting upon objects. I generally use 'Manager' when the class is proactively managing rather than just providing a service. Further, if it acts upon the object rather than returning the "answer" the caller is after (the approach mockists apparently prefer from martin fowler's article http://martinfowler.com/articles/mocksArentStubs.html) , I generally call these Managers rather than Service but that's just a rule I've developed.
ALSO.. I watched a video on youtube a few months back from Rod Johnson where he talked about moving more of the business logic out of the services and into the domain objects [at least from my memory] because this is where you can easily get code reuse. This makes sense to me because often the domain/model is the comment component and the services are often application specific and therefore not as likely to be reusable. Having said that I have yet to really utilize this in practice. Ideally we would define in which package(s) the business logic should go, as well as common "rules" or troubles (e.g. try to avoid state here or synchronise it for thread safety or these typically are injected or get injected into others, etc. )
Other things that would be interesting to include is ibatis, and where bus logic goes here.
hopefully this already exists and someone can point me to it!