UI Workflow is business logic

Sun, 26 Sep 2010 21:42:00 GMT

Over my years as a programmer I’ve focussed a lot of attention and energy on business logic. I’m sure you have too. Business logic is, after all, a huge part of what our clients/end users want to see as an output from our development efforts. But what is included in business logic? Usually we think of all the conditionals, looping, data mangle-ment, reporting and other similar things. In my past experiences I’ve poured immense effort into ensuring that this business logic was correct (automated and manual testing), documented (ubiquitous language, automated testing and, yes, comments when appropriate) and centralized (DDD). While I’ve had intense focus on these needs and practices, I’ve usually neglected to recognize the business logic that is buried in the UI workflow within the application.

On my current project I’ve been presented with an opportunity to explore this area a bit more in depth. We don’t have the volume of what I have traditionally considered business logic. Instead the application is very UI intensive. As a result I’ve been spending a lot more time worrying about things like “What happens when the user clicks XYZ?” It became obvious to us very early on that this was the heart of our application’s business logic.

Once I realized this we were able to focus our attention on the correctness, discoverability, centralization and documentation of the UI workflow. How did we accomplish this then? I remember reading somewhere (written by Jeremy Miller I think, although I can’t find a link now) the assertion that “Every application will require the command pattern at some point.” I did some research and found a post by Derick Bailey explaining how he was using an Application Controller to handle both an Event Aggregator and workflow services. To quote him:

Workflow services are the 1,000 foot view of how things get done. They are the direct modeling of a flowchart diagram in code.

I focused on the first part of his assertion and applied it to the flow of user interfaces. Basically it has amounted to each user workflow (or sequence of UI concepts) being defined, and executed, in one location. As an example we have a CreateNewCustomerWorkflowCommand that is executed when the user clicks on the File | Create Customer menu. It might look something like this:

1: public  class  CreateNewCustomerWorkflowCommand  : ICommand <CreateNewCustomerWorkflow >

2: {

3:     private  readonly  ISaveChangesPresenter  _saveChangesPresenter;

4:     private  readonly  ICustomerService  _customerService;

5:     private  readonly  ICreateNewCustomerPresenter  _createNewCustomerPresenter;

6:

7:     public  CreateNewCustomerWorkflowCommand(ISaveChangesPresenter  saveChangesPresenter,

8:                                             ICustomerService  customerService,

9:                                             ICreateNewCustomerPresenter  createNewCustomerPresenter)

10:     {

11:         _saveChangesPresenter = saveChangesPresenter;

12:         _customerService = customerService;

13:         _createNewCustomerPresenter = createNewCustomerPresenter;

14:     }

15:

16:     public  void  Execute(CreateNewCustomerWorkflow  commandParameter)

17:     {

18:         if  (commandParameter.CurrentScreenIsDirty)

19:         {

20:             var  saveChangesResults = _saveChangesPresenter.Run();

21:             if  (saveChangesResults.ResultState == ResultState .Cancelled) return ;

22:             if  (saveChangesResults.ResultState == ResultState .Yes)

23:             {

24:                 _customerService.Save(commandParameter.CurrentScreenCustomerSaveDto);

25:             }

26:         }

27:

28:         var  newCustomerResults = _createNewCustomerPresenter.Run();

29:         if  (newCustomerResults.ResultState == ResultState .Cancelled) return ;

30:         if  (newCustomerResults.ResultState == ResultState .Save)

31:         {

32:             _customerService.Save(newCustomerResults.Data);

33:         }

34:     }

35: }

As you can see the high level design of the user interaction, and service interaction, is clearly defined here. Make no mistake, this is business logic. It answers the question of how does the business expect the creation of a new customer to occur. We’ve clearly defined this situation in one encapsulated piece of code. By doing this we have now laid out a pattern whereby any developer looking for a business action can look through these workflows. They clearly document the expected behaviour during the situation. Since we’re using Dependency Injection in our situation, we can also write clear tests to continuously validate these expected behaviours. Those tests, when done in specific ways, can also enhance the documentation surrounding the system. For example, using BDD style naming and a small utility to retrieve and format the TestFixture and Test names we can generate something like the following:

1: public  class  When_the_current_screen_has_pending_changes

2:  {

3:     public  void  the_user_should_be_prompted_with_the_option_to_save_those_changes(){}

4: }

5:

6: public  class  When_the_user_chooses_to_cancel_when_asked_to_save_pending_changes

7:  {

8:     public  void  the_pending_changes_should_not_be_saved(){}

9:     public  void  the_create_new_customer_dialog_should_not_be_displayed(){}

10: }

11:

12: public  class  When_the_user_chooses_not_to_save_pending_changes

13:  {

14:     public  void  the_pending_changes_should_not_be_saved(){}

15:     public  void  the_create_new_customer_dialog_should_be_displayed(){}

16: }

17:

18: public  class  When_the_user_chooses_to_to_save_pending_changes

19:  {

20:     public  void  the_pending_changes_should_be_saved(){}

21:     public  void  the_create_new_customer_dialog_should_be_displayed(){}

22: }

23:

24: public  class  When_the_user_chooses_to_cancel_from_creating_a_new_customer

25:  {

26:     public  void  the_new_customer_should_not_be_saved(){}

27: }

28:

29: public  class  When_the_user_chooses_to_create_a_new_customer

30:  {

31:     public  void  the_new_customer_should_be_saved(){}

32: }

As you can see, this technique allows us to create a rich set of documentation outlining how the application should interact with the user when they are creating a new customer.

Now that we’ve finished implementing this pattern a few times, have I seen any drawbacks? Not really. If we didn’t use this technique we’d still have to write the code to coordinate the screen sequencing. That sequencing would be spread all over the codebase, most likely in the event handlers for buttons on forms (or their associated Presenter/Controller code). Instead we’ve introduced a couple more classes per workflow and have centralized the sequencing in them. So the trade off was the addition of a couple of classes per workflow for more discoverability, testability and documentation. A no brainer if you ask me.

Is this solution the panacea? Absolutely not. It works very well for the application that we’re building though. In the future will I consider using this pattern? Without doubt. It might morph and change a bit based on the next application’s needs, but I think that the basic idea is strong and has significant benefits.

A big shout out to Derick Bailey for writing a great post on the Application Controller, Event Aggregator and Workflow Services. Derick even has a sample app available for reference. I found it to be great for getting started, but it is a little bit trivial as it only implements one simple workflow. Equally big kudos to Jeremy Miller and his Build Your Own CAB series which touches all around this type of concept. Reading both of these sources helped to cement that there was a better way.

Rotating text using Graphics.DrawString

Wed, 09 Jun 2010 10:06:17 GMT

Recently I needed to create a custom WinForms label-like control that allowed for the text to be displayed in a rotated fashion. Our needs were only for four rotation locations; 0 degrees (the default label position), 90, 180 and 270 degrees. There were other complicating factors, but for this post we’ll only concentrate on this component of the control.

To rotate text using the Graphics.DrawString method you only have to do a couple of things. First you have to use the Graphics.TranslateTransform method, then the Graphics.RotateTransform method, and followed by the Graphics.DrawString. Here’s what it looks like.

using (var brush = new SolidBrush(ForeColor))
{
    var stringFormat = new StringFormat
                       {
                           Alignment = StringAlignment.Near,
                           LineAlignment = StringAlignment.Near
                       };
    e.Graphics.TranslateTransform(transformCoordinate.X, transformCoordinate.Y);
    e.Graphics.RotateTransform(rotationDegrees);
    e.Graphics.DrawString(Text, Font, brush, DisplayRectangle, stringFormat);
}

What you see are the three steps that I outlined above. Let’s start at the bottom and work our way up. The code exists inside of a UserControl’s overridden OnPaint event. The DrawString method makes use of some of the properties on the control, like Text and Font. It also uses the DisplayRectangle property to set the boundaries for the drawing to be the same size as the control. This is one of the keys to making the rotations work. The other key is to provide the DrawString with the StringFormat settings. By setting them to be StringAlignment.Near for both the Alignment and LineAlignment, you are declaring that the text’s location should be based in the top left of the DisplayRectangle’s area.

Graphics.RotateTransform is how you set the rotation value. In the case of our control, we would be putting in a value from the list of 0, 90, 180, and 270. As you might expect the rotations are clockwise with 0 starting with the text in the ‘normal’ location.

Graphics.TranslateTransform is where the last piece of magic occurs. It is here that you set where the top right corner of the text drawing area will be located in the DisplayRectangle’s area. Here are some images that will help clarify the situation.

When you need the text to appear the same as “Text Area” does in the above image (rotated 0 degrees), you need to set the TranslateTransform X and Y parameters to be those that are designated by the “X” in the image. In this case, it’s X=0 and Y = 0.

The picture above shows you what you should be displayed when you are rotating the text “Text Area” 90 degrees. Again, you need to set the TranslateTransform, but this time the values are slightly different. The Y parameter is still 0, but the X parameter equals the height of the text. You can get this value by using the following line of code:

var textSize = TextRenderer.MeasureText(Text, Font);
textSize.Height;

To render the text upside down we set the rotation to 180 degrees and then, again, determine the location of the TranslateTransform X and Y coordinates. Like we did for the last rotation, we will need to retrieve the text size to set these values. For this situation Y will be the text height and X will be the text width.

The final step is to make the rotation work for 270 degrees. Like all the others, we need to set the X and Y coordinates for the TranslateTransform method call. Here the Y value will be the text width and the X value will be 0.

This is simply the first step of many to making a control that will allow rotation of the text and locating it in one of 9 locations in a 3x3 grid representation of the control’s DisplayRectangle. More on that in another blog post though.

igloocoder.com

UI Workflow is business logic

Rotating text using Graphics.DrawString