Separating UI code from everything else

For some time now I’ve been trying to improve the seperation of my application code from the user interface (sometimes with more success than others). This is a known good practice, and yet I regularly see code (yes, even code that I’ve written) where business logic has “leaked” into the UI.  A useful “thought experiment” I often use is “How much of this code would I have to change if I wanted to re-write this as a console application?” (or whatever UI type I’m NOT using in the current app I’m writing). A number of times I think this has helped put things in perspective for me, or at the very least be more explicit about my assumptions. Recently I finished working on a small-ish utility of my own and decided it would be useful if there was a command line version. I was fairly pleased with the results - I ended up moving one method from the UI (which really didn’t belong there) down into the “business” tier. I was equally pleased when I saw almost no duplicated code between the console UI and WinForms UI. I would reccomend it to anyone who would like to REALLY see how de-coupled their UI is from their business objects.

Comments

Mark
Agree. This is a "best practice" that we try to stick to as much as we can. If time is an issue, at least put the business logic in another class within the same project. This will give the option of separating the business tier out later on.
10/11/2003 9:37:00 PM
Paul
Hi, Joseph. Try the Microsoft User Interface Application Block. It uses the Model-View-Controller pattern and it really rocks
11/11/2003 9:52:00 AM
JosephCooney
Yes Paul, I’ve been meaning to check that one out for a while now. Until I do I can’t say how much it helps keep the seperation explicit, altho I’d hazard a guess that it will still take developer vigilance to keep the two seperate.
11/11/2003 10:02:00 AM