I’ve set up my project folder layout and it looks like this:
There are many project folders, but we don’t need to worry about it because maven will look after the building for me. Lets have a closer look at the each of the project folders
The beans folder will contain a whole bunch of EJBs that do a bit of logic, factories, utils etc. It’ll the place to put the EJBs, keeping in mind that we don’t need to have beans implementing interfaces, I’m going to try do away with the interface classes all together – they mostly are just bloating the code base anyway.
This is a very important project, this is our “APIs” that will be shared with 3rd parties. Although they can use my webservices using their own client, it’s a to have a client written for you that you just use. Amazon have done a super job of providing client libraries and really should be something to release to the world. This is just not for 3rd parties though, I’ll be using within my own beans to make webservices calls (more on why this is a good and bad idea in another blog when I’ve got around to actually writing client code).
I’m all for not using entities in my project, I’m starting to side with the fact web like services are actually hindered by entities, but that is another topic for another day. For now, this will be here readily available in case I find it too much of a burden.
This is where all the real SQL queries will live. I’ll be using JPAs connection pooling (ie. the entity manager) to call a bunch of native queries. In the bigger abstract picture, you can see this a ‘the database’ for the application, so if I change from mysql to something else, only this project will ever need a bit of a re-write.
This is where the implementations of the restful web interfaces will be written, also a bit of behind the scenes magic will happen here. It will mainly call out to the beans to do all the work.
This is a very basic and very simple project to keep the data objects that are used to and from external sources via the web service. If you will, it’s the java objects that represent the JSON that is passed between client and web service.
The interface classes are sitting outside of the web project because we might use those interfaces in a client or another version of our services. Also, it allows us to expose and show off that one project without worrying about actually code going out in the case we want other people to implement or extend the interfaces. Might be a bit overkill but I’m going to stick with it.
This one is a bit of experimentation for me. This is where other services that exist outside of a web call will exists. This includes some cron jobs, back end shortcuts, reports, monitoring and the such. I could have put all this into the beans project, but I want to try keep client facing code and internal facing code implementations as separate. Webservices will use the beans or REST calls if needs.
I have an idea that unit tests, in the bigger picture of things, are not really something I’m going to go for. I’ll be using the junit framework to run integration like tests from this project. This project may even become a Chaos Monkey.
Lastly, the ear project that is just there to package everything into a nice single file.
It looks like serious overkill of project folder structure for sure. I think in long term having smaller projects will help keep separations of layers and groups code with the same objectives together is a way to go. Let see how it turns out.