DaniWeb Forum Index > Software Development > C#

C# RSS

Seperating UI code

Please support our C# advertiser: Intel Parallel Studio Home

•

Join Date: Oct 2009

Posts: 34

Reputation: RunTimeError is an unknown quantity at this point

Solved Threads: 3

RunTimeError RunTimeError is offline

Offline

Light Poster

Seperating UI code

Nov 2nd, 2009

Hey guys,

I just have a question regarding the separation of UI code from business/logic code. I always seem to get in trouble for putting to much code in form classes. I don't understand where the line is drawn between code that needs to be in form/UI code vs code that needs to be put in a separate class. Further it seems a bit over kill to have to create a separate class and do logic in there just to do something simple. Lastly, what is the point? I really don't understand what the big deal is. I know that it is good practice but I mean is it really that big of an issue? In the example below I am getting the time and bringing up a message box. Now normally I would put this into the form code:

Form1.cs (UI Code)

 Help with Code Tags 
 C# Syntax (Toggle Plain Text) 
int hour = DateTime.Now.Hour;
 
if(hour == 12)
{
      MessageBox.Show("It's time")
}
int hour = DateTime.Now.Hour;

if(hour == 12)
{
      MessageBox.Show("It's time")
}

By definition this is logic so I need to make an entirely separate class to satisfy the "separation of UI" rule such as I have done below?

Form1.cs (UI)

 Help with Code Tags 
 C# Syntax (Toggle Plain Text) 
timelogic timeClass = new timelogic();
 
if(timeClass.returnTime())
{
      MessageBox.Show("It's time")
}
timelogic timeClass = new timelogic();

if(timeClass.returnTime())
{
      MessageBox.Show("It's time")
}

timelogic.cs

 Help with Code Tags 
 C# Syntax (Toggle Plain Text) 
public bool returnTime()
{
     int hour = DateTime.Now.Hour;
 
     if(hour == 12)
    {
        return true;
     }
     return false;
}
public bool returnTime()
{
     int hour = DateTime.Now.Hour;

     if(hour == 12)
    {
        return true;
     }
     return false;
}

It seems to be a bit over kill. I get even more confused because I am using logic within my form class to bring up a message box so am I breaking the rule? Can someone explain the proper method for separating logic/business code from UI code?

•

Join Date: Mar 2008

Posts: 332

Reputation: Diamonddrake is a jewel in the rough

Solved Threads: 39

Diamonddrake Diamonddrake is offline

Offline

Posting Whiz

Nov 2nd, 2009

That's really up to the programmer. If you work for a company that expects this, then its up to them, but if you are just writing software by your self it doesn't really matter.

The big selling point of putting logic in classes is portability. once you have written it once, you can easily use it in other applications. another thing is it keeps your code organized, so in a large application its easier to find and edit your code.

but writing a class for 10 lines of code that could easily be condensed into 5, that's just silly.

•

Join Date: Nov 2009

Posts: 1

Reputation: crazy_coder is an unknown quantity at this point

Solved Threads: 0

crazy_coder crazy_coder is offline

Offline

Newbie Poster

Nov 2nd, 2009

As replied above, It depends on the type of program you are writing. The programmer should be able to draw the line where to put the functionality depending on the complexity, and requirements. Yes, you should not be too sensitive to this issue. it will suck your time in decision making of where to put the code rather writing a working solution.

Last edited by crazy_coder; Nov 2nd, 2009 at 3:06 am.

•

Join Date: Oct 2009

Posts: 63

Reputation: mikiurban is an unknown quantity at this point

Solved Threads: 16

mikiurban

Offline

Junior Poster in Training

Nov 2nd, 2009

Actually, it's not up to the programmer, it's up to whoever approves the code

There are an unlimited degrees of "how much is too much" in either direction. If your boss/teacher doesn't think it's separated enough, then it isn't. Your next supervisor will most likely be different. It boils down to development speed vs. portability: it's faster to create code without all of this abstraction, but you may never be able to use it anywhere else.

For me, a good rule of thumb is "how often will I be using this logic?" and if it's more than in two spots, then I separate it out. For example, there are now several ways to open a file: File menu -> Open, or the button on the toolbar, or Ctrl+O, etc, so it makes sense to have a separate function that goes through the whole "show dialog, see if he clicks OK or cancel, read the file, prepare UI" process. In your example, if you only check the time in one place for your whole program, then separating it out may be overkill. But if you are checking it all over the place, then it makes sense.

Another way to look at it: if I have to make a change to this logic (in your example, what if you also need to compare it to 0, to handle midnight), how many places do you need to make the change? if you spend too much time trying to make changes to your code instead of programming, it might be a good idea to split it up.