Posts:
2
Registered:
1/1/08
|
|
|
|
How to design session facde in Struts 1.2 based application
Posted:
May 18, 2008 10:50 PM
|
|
Hi
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
|
|
Posts:
30
From:
London
Registered:
6/13/06
|
|
|
|
Re: How to design session facde in Struts 1.2 based application
Posted:
Sep 27, 2009 6:39 PM
in response to:
Jacobdeiter
|
|
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.
|
|
|
Legend
|
|
Gold: 300
+
pts
|
|
Silver: 100
- 299
pts
|
|
Bronze: 25
- 99
pts
|
|
Manning Author
|
|
Manning Staff
|
|
