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.

Friday, April 27, 2007

Intention Driven Design

People who use code to communicate their ideas of software design should give their unit tests along with their implemented code. To me that only seems to be polite. If you’re going to be on a discussion group that has its main focus to be unit testing, you should give examples in unit tests. Give me your intention not your implementation. I really don’t care if you used a long or an integer to implement a counter inside your implementation. If unit testing is the documentation of the code and no other documentation is needed, why is so much implementation used in examples?

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)
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);

          return mBody = mu.Module;

      public string GetFormattedBody()
          ModuleFormatter mf = new ModuleFormatter(mBody);
          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.


Just got done finishing my implementation of Martin Fowler's 2 pass build reader for DSLs: I wish he would have added the reflection code. It really sucked trying to figure out all the reflection for dynamic assembly. 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.

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