The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Jacobdeiter (2) [Avatar] Offline

How to design POJO based Session facade in Struts 1.2 ,Spring 2.0,Hibernate 3.1 based web application.I read the book "Pojo In Action".In that is was given session facede.Thx in advance
simbo1905 (30) [Avatar] Offline
Re: How to design session facde in Struts 1.2 based application
I would do the process as outlined in the early chapters of the book:

* Write out the use cases (the short stories of how the users use the system)
* Work out which Domain Model classes need to be involved (which record entities, re-usable services and repositories). In the book this is captured as a UML class diagram for the use case. Think what new methods will have to be added to the domain classes to implement the use case (e.g. new findXbyY method on the repository class for entity x).
* For a given use case figure out what new or existing Facade class to add a method to which encapsulates the logic of the use case.
* Write out the facade method to implement the path through the use case in a high level manner ignoring any presentational matters or html input processing which should be left to the struts actions. A good high level to write design a method is to use the approach outlined in chapter 3 of the book Clean Code by Robert C. Martin particular page 37. That technique in that book encourages small methods that a very readable.
* Now thats the design phase over. Now write junit tests for each Domain Model method you are going to write using mock objects. Only after the tests are written and have failed do you write the code of the new domain object methods to make the tests pass.
* Finally write your facade junit test and once they are written and failed do you write the code to implement the facade to make the test path.
* Finally write the struts action to call the facade method. If you are going to have one developer write the screens and actions and another write the facade you can consider giving the screen developer a mock facade which is a basic class which returns static dummy data that she can use whilst the real facade is being developed.

Notice that the starting point is the "what needs to happen logically" which is a use case that says what actor is to what with the system (rather than a screen design description). Then it is the "what generic things will be written to do the logic" which is the domain model design. Then you do the facade to enact the use case with the re-usable domain model objects. Finally you hook up the actions to get the screen to work.