Hi all, I've been struggling with some design questions in some wicket projects lately, and hope to get some insights from fellow wicketeers.
Some years ago I started with Databinder as a DAO layer, without a service layer. This led to UI code building queries or adding Restrictions to a jpa (hibernate) query. After working like that on some smaller projects, I came across warp-persist and started using that (plus guice). Great! many new possibilities. However, ever since I started using those tools, I have ended up with the following: - JPA Entities - DAO interface per entity, with a (guice-bound) implementation - UI either calls DAO methods directly for loading data, or specialized IDataProvider implementation which takes a DAO and allows the UI to add filters (e.g. a filter based on a "search by name" field). - "Service layer" which is more or less based on the "Transaction script" pattern (as described by Martin Fowler); this contains specific use cases, such as cases where multiple objects need to be dealt with in a separate transaction (@Transactional) However, the above gets messy quickly. There are different ways to get to the data: in some cases the UI calls DAOs directly, and sometimes a service should be used since it does extra filtering etc. So lately I started to wonder if I should make the UI only call the service layer... Which would lead to a lot of extra classes and code which merely forwards calls to the DAOs. Especially when combined with IDataProvider it leads to a lot of UI-specific (findByXandY, findCountByXandY) methods in both the DAO and service layer. I decided to take a step back and re-evaluate. I only work on projects for my own firm (so no external projects), and unfortunately do not have access to people who have experience with these sorts of architectural design issues. Well, of course there is the option of outsourcing, which I've tried in a few projects; But let's just say that the resulting apps were by no means well designed, even though the price was relatively high (small project, 40.000 euro cost). Recently I picked up "Domain Driven Design" by Eric Evans, and I like what I am reading. Since most of my projects are small, I don't want to add many layers to make things more complicated. However, I do want separation of concerns (e.g. a clear boundary/layer for security, transactions). Injecting services into my entities seems wrong to me, and I certainly don't want to go the RoR ActiveRecord direction (all logic in entities, been there didn't like it). Since the projects are small, the effects of relatively "unclean" code are negligible. On the other hand I am a purist (and a perfectionist), eager to learn and improve; Also, some projects become more and more important (e.g. handling millions of dollars worth of transactions), and keep on growing. Due to lack of experience in bigger projects I feel like I keep on struggling with this without having a clear focus. It would really help me to hear from other how they layer their wicket apps and why. Thanks in advance for reading, and for posting a reply! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/OT-Best-practices-regarding-service-layers-DAOs-tp2400408p2400408.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
