Event Sourcing Revisit

Ah... Encapsulates Application State as derived from event/command messages. Pretty sweet.

Event Sourcing

Was looking over event sourcing. I'm still trying to scratch my head. Will Keep plowing ahead and leave more remarks

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.

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.

DSL

Just got done finishing my implementation of Martin Fowler's 2 pass build reader for DSLs:

• Language Workbenches
• Code Generation DSL

I wish he would have added the reflection code. It really sucked trying to figure out all the reflection for dynamic assembly. Phew...got it anyway. Works sweet!

Did run across CodeDom. This will generate code. The next step would be to generate the dynamic assembly with CodeDom. Some how I want to use this after loading up the reader strategy. Looks like some abstraction is required. Refactor...Refactor.