I am working on class diagram and stuck in presentation tier design.
In business and persistence tier, I have design couple of Services and DAOs.
All of them are EJB Stateless Session Beans and I assume DI is used.
So in presentation tier, I have to call the service in Servlet otherwise DI won't work (I don't use JSF cuz I am not familiar with JSF).
It turns out I need to create one servlet for each use case
and a front controller servlet to handle all requests from clients then dispatch to each action servlet to call service EJB.
I suggest you'd better use JSF, it will eliminate the need of additional controllers, servlets and other stuff. Even if you haven't done projects with JSF the theory you learned in the first part should be enough to design system with JSF. Don't reinvent the wheel, just use best practices
Ionut, From JSF I've displayed only JSP pages connected to controller (I've displayed it as a Controller, but in real life it's FacesServlet) on the class diagram, It's how it is done in the new book, strange solution but i preferred to do according to the book. I didn't show any classes of the framework and not ManagedBeans. However I've included JSFs and managed beans on my sequence diagrams
The reason why I use DAO is because of the flexibility to replace the data persistence mechanism.
For example, if one day for some reason you can't use the relational database, you can easily switch to another persistence mechanism like XML file. If you inject EntityManager in your service implementation, you won't be able to switch to another persistence mechanism without changing your service implementation.
DAO may be reasonable in small systems, or to read configuration or in export/import implementations where you sometimes want to export to the database and sometimes to the file.
When it comes to the large enterprise systems, the probability that this system will need to use files instead of database is near to 0. what will be possible is the need of switching database engine (e.g. Oracle instead of DB2), and this will be even easier with JPA, because it has implementations suitable for most of the relational databases.
Dmitri did you used any design patterns?
Most of them are coming with the frameworks:
jsf-interception filter, front controller, composite view
jpa-value object, value list handler
Facade, factory, adapter patterns are good candidate to use with jsf.
Not sure about business delegate, but I guess if you don't have multiple client types(only jsf, maybe also web services) it might not be used.
Where do you use Builder and Abstract Factory for object creation?
Do you use it in controller to create object such as Request or Bid, so it can store parameter value and pass to JPA for persistence?
Not to reveal assignment details, but my system is designed to build objects and connect substitutable components. I use factories for creating various related components and builder to compose main object from those components. I use them in Application service, which is called from presentation tier, after creation they are persisted with JPA.