Ad:

C# Discussion Thread
Unsolved
Views: 549

Nov 2nd, 2009

Seperating UI code

Expand Post »

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)

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)

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

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?

Similar Threads

Gray Code Conversion in C
Sample code for taking user input from Shell in Java
code to split (and reconnect) an Access database (part 1) in Visual Basic 4 / 5 / 6
Strings: Looking at ASCII Code in C
code to validate data in Access withOUT using messageboxes in Visual Basic 4 / 5 / 6

RunTimeError

Reputation Points: 10

Solved Threads: 3

Junior Poster in Training

Offline

54 posts
since Oct 2009

Permalink

Nov 2nd, 2009

Re: Seperating UI code

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.

Diamonddrake

Reputation Points: 442

Solved Threads: 89

Master Poster

Offline

721 posts
since Mar 2008

Permalink

Nov 2nd, 2009

Re: Seperating UI code

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.

crazy_coder

Reputation Points: 10

Solved Threads: 0

Newbie Poster

Offline

1 posts
since Nov 2009

Permalink

Nov 2nd, 2009

Re: Seperating UI code

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.

mikiurban

Reputation Points: 27

Solved Threads: 17

Junior Poster in Training

Offline

63 posts
since Oct 2009

This thread is more than three months old

No one has posted to this discussion for at least three months. Please let old threads die and do not reply to them unless you feel you have something new and valuable to contribute that absolutely must be added to make the discussion complete. Otherwise, please start a new thread in this forum instead.

Previous Thread in C# Forum Timeline: Big Numbers Problem

Next Thread in C# Forum Timeline: Noobie: Help with executing command line exe and parameter

DaniWeb Message

Cancel Changes

User Name
Password