C#, separating message display code from the business logic

Question

I have a winforms application and I'm not following any kind of design pattern. My problem is, I have these base classes which contain all my business logic. When ever an exception occurs or I need to display a dialog box to the user, I have written the code directly into the base classes where I need it.

I know that I need to separate my business logic and display logic, so I wrote a static class that includes the methods that I need to display the messages with.

My question is, is there an easier way to separate business logic from the display?

my static methods look like this,

public static void DisplayMessage(string message) 
    {
        MessageBox.Show(message);
    }

 public static bool DisplayDialogBox(string message,string caption ) 
    {
        DialogResult newresult = new DialogResult();

        newresult = MessageBox.Show(message,caption,MessageBoxButtons.OKCancel);

        if (newresult == DialogResult.OK)
        {
            return true;
        }
        else 
        {
            return false;
        }  

So I'll be calling these methods from the base classes, like

MsgDisplay.DisplayMessage(e.Message);

and is this method a good practice?

Answer 1

No, this method is not a good practice. There is no any difference between your class and MessageBox class.
See, with your class:

MsgDisplay.DisplayMessage(e.Message);

and just using MessageBox

MessageBox.Show(e.Message);

This wrapper doesn't provide any additional functionality.
If you want to separate business logic and ui, then you have to break down your methods and display message only in UI layer.
And, small point. Instead of:

if (newresult == DialogResult.OK)
    {
        return true;
    }
    else 
    {
        return false;
    }

type just:

return newresult==DialogResult.OK

UPDATE: If all you want to display is exception message then you should catch exception and show message on UI layer. So in your business class instead of displaying message:

void foo() {
   try {
       //some code here
   }
   catch(FooException fe) {
       MessageBox.Show(fe.Message);
   }
}

throw exception to the ui layer:

void foo() {
   try {
       //...
   }
   catch(FooException fe) {
       //throw new BarException("Error occured: "+fe.Message); //if you want to customize error message.
       throw; //If you don't need to change the message consider to not catch exception at all
   }
}

and then display the message outside of the business logic:

void fooButton_Click(object sender, EventArgs args) {
   try {
        fooBusinessClass.foo();
   } catch(FooException fe) {
        //if(MessageBox.Show(fe.Message)==DialogResult.OK) fooBusinessClass.continuefoo(); //if you have several options
        MessageBox.Show(fe.Message);
   }
}

Answer 2

I typically create an IView interface which is then injected into the business logic classes. If the logic "has a question" it needs to get user input it would then go like this:

interface IView
{
     bool AskUser(string question);
}

class SomeClass
{
     IView _View;

     public SomeClass(IView view)
     {
        _View = view;
     }

     public void SomeLogic()
     {
          if (someCondition && !_View.AskUser("continue?"))
               return;
     }
}

And then your form can implement IView to ask the user via message box prompt. For unit testing you can mock out the view which you can't really do in the static design case.