Regarding Wicket and GWT : it is true that they "easily" let you code complex UIs, but they have IMHO a great flaw : they make separation of concerns useless, forcing developers to produce a lot of Java code.
Why need developers need to produce a lot of code, those full bloated JSP pages aren't a pretty sight either ... but you have to write something don't you a gui doesn't appear on the screen with some magic trick. But if you need to decide between JSP, tags, ... or a fully maintainable, testable GWT, I think I'm going to take the GWT road, I've made just TOO many complex business web apps to not see the GUI creation / maintenance / testing problems. Things tend to get more complex every project, and I don't thing fighting complexity with a scripting or tag related language is going to help us lowering time-to-market.
It's not clean to keep the complete session open
Repositories have a different granularity than DAOs: there's usually one repository per aggregate root, because root entities are the only one with independent lifecycle, while other entities should be "saved" and "retrieved" through their relative root entities.
I also use injection of repositories for complex aggregates. But I must admit that for simple entities, I sometimes use the DAO directly. For complicated aggregates, repositories contain domain logic in addition to accessing the DAOs for data fetching purposes. And the contract for the Repository nicely abstracts away all these complications from the actual entity. From that point of view, ONE repository can *contain* MULTIPLE DAOs, each corresponding to the respective table in the database. And finally, I use interfaces as the contracts for repositories
Here's some other post I wrote in responding to almost the same scenario presented to justify DTOs. On top of that, I'd say that, yes, it would be cleaner to have a specific view model, but that kind of cleanness should not come at the price of a fragile service API/implementation (unless justifiable by some significant performance gain). In other words, I would assemble the view model from DO's in my presentation layer, not the service layer - which makes it just a view model, not a DTO.
Some other random thoughts
- So you have designed the company business into your domain model, it all looks great, the idea will serve for years... BUT (yes there is always a 'but' in IT lolz) business rules tend to change faster than project can be completed. So what about using domain models in combination with rule engines i.e. Drools, anyone has any good or bad experiences with that?