...
Separation of concerns
One of the curcil crucial lessons of working with FtiNesse is that you should not place all the logic in the fixture. In actual fact it’s bad practice to place your logic in the fixture. The fixture should be used as a gateway to your business classes. What we actually want to do is to create a separation between your business logic and the fitnesse harness as shown here
This model makes it possible to view the contents of the business objects through any channel, a GUI, Web page or even a fixture. If we didn't provide the Business Session Object above, each of the channels shown would have to provide the same logic to coordinate the behaviour of the Business Objects. So what you would actually see is that the channels are poluted with Business Object informationand the Business Objects are polluted with channel information. Which would make changing either side difficult and after a while the whole code base would become unmaintable.
A better way to understand this model is to think of it in terms of UML use cases
...
A use case represents the sequence of interactions between the actor and the system to achieve a business goal. When we translate UML models to code, it is good practice to create a class for each use case. We call these <<controllers>>. They are essentially objects that coordinate business objects to achieve the business goal. You might be wondering why si is there a Calculate Pay but no Format Time. Well, the whole purpose of the application is to calculate the correct pay (read the initial requirements), the problem was that the time entries were in the wrong format, so formatting the time is not a business goal.
Now we have this use case model, our above model would be better modelled as follows
Notice that each use case has its own controller.
Wiring the model
A fitnesse fixture is active for the lifetime of a fitnesse test page. So each row of data is pumped into the single instance of an instantiated fixture. So for the above model to work one approach is make your controllers singletons, each being accessed by several fixtures. Each of these fixtures are called from a single fitnesse test page, as the model below shows. By wiring your model like this, it is possible to pass data between fixture tests on the same fitnesse page.
...