Showing posts with label Presenter First. Show all posts
Showing posts with label Presenter First. Show all posts

Friday, May 4, 2007

Presenter First Events

To keep track of the presenter first event connection, use a sequence diagram. The diagram is driven from Atomic Object's Ruby Code.

Saturday, April 28, 2007

New Stab At Presenter First

Presenter First: Mappers. Plain and simple. Maps events to actions/commands required on the injected objects in the presenter.

  • Benefit is that all the models and views can be isolated from each other so that they can change on their own. Views especially don't need to know about models.
Something else, It seems to me an event aggregator could replace all the presenters with only one presenter and store all actions/commands in a table. Need only to pass all models and views into aggregator. Need to define the mechanics for this refactoring.

Wednesday, April 11, 2007

Presenter First #2 (Application Data)

Normally there are 3 data states in Presenter First design.

  • Record State. The persistent data store residing in the Data Layer. This could include RDBMS, XML, or text flat files.
  • Session State. Stored in-memory within application. Usually Data Transfer Objects.
  • Screen State. Data stored in the view.
It is very important the Session State and the Screen State remain synchronized. That is where the presenter object comes into play. The session data becomes dirty and generates an event to the Presenter. In my implementation the Presenter would then query the view for actiontype, check if view is in dirty state, if dirty retrieve DTO from view. Presenter would then pass DTO to the Domain Service to save the DTO information. Code Example follows:
public class ReformatAction : CommandAction
{
public ReformatAction(ViewAggregator viewAggregator,
 DomainService domainService) : base(viewAggregator, domainService){}

public override void Execute()
    {
     string formatModuleName = ViewAggregator.GetSelectedModuleName();
        ModuleDTO moduleDTO = ViewAggregator.GetModule();

        if (ViewAggregator.IsDirty)
             Service.SetModule(moduleDTO);
        ViewAggregator.SetModule(Service.GetModule(formatModuleName));
    }
}
This code example is the wiring between the view and domain. It is a command object. It pulls the module name from the view, pulls the module, if view is dirty then save module, reload saved module to view. The formating comes from where? See what happens in the service:
      public void SetModule(ModuleDTO module)
     {
          mModuleTable[module.GetModuleName()] = module.GetBody();
     }
So we see that it is all done in the service. But you say your unformatting and saving the unformatted int the module table. Correct. Look at this piece:
        public string GetBody()
      {
          ModuleUnformatter mu = new ModuleUnformatter(mBody);
          mu.UnformatModule();

          return mBody = mu.Module;
      }

      public string GetFormattedBody()
      {
          ModuleFormatter mf = new ModuleFormatter(mBody);
          mf.FormatBody();
          return mf.Module;
      }

Ask yourself why didn’t I just transfer the formatted directly into the text box…

Next Post #3: How to utilize command pattern so that the Presenter holds no instance of Domain or View and is nothing but command messages and event messages.

Post #4: Either Mocking and Unit Testing Presenter First or Event Handling.

Sunday, April 8, 2007

Presenter First

Presenter First is a pattern that includes Event Mapper (Presenter), Domain (Model), and Server (View) objects.

Figure 1.
The key point when designing with this pattern is to remember to keep the presenter stateless. Don't do any data manipulation in the event handling. Do it all in the Domain. Example:
You notice in the correct code you are using command messages to transfer the data around from Server (viewService) to Domain (domainService) and vice versus. All I am doing is wiring up the Server to to the Domain and Domain to Server. Next Post #2: How to utilize command pattern so that the Presenter holds no instance of Domain or View. Post #3: Encapsulation worth the effort for Presenter First? Post #4: Either Mocking and Unit Testing Presenter First or Event Handling. References: AtomicObject Marting Fowler Brian Marick Michael Feathers