views:

251

answers:

5

What are the fundamental techniques to make most part of my C# source code UI independent?

For example, I would like to write my source code for Winforms desktop application which I shall be able to plug into asp.net web application or a WPF application with very minor changes. I.e. I shall be able to use the same source code irrespective of UI technology to make it future-proof.

I know CSLA framework can do that.

But if I don't use CSLA (it takes some time to learn a new framework and at present I don't have that much time to spend on it), what points should be taken care of to achieve this kind of ability in my C# code?

Can you give me an example? I already use Business Objects and layering technique in my applications. But even so I have seen that it needs a lot of coding to plug my code to new UI technologies.

Please do not provide me with any superficial answer.

+10  A: 

The best way to do UI independent coding is to seperate the logic from the presentation. Take a look at the MVC pattern.

This is more of an discipline issue with your design rather than a framework issue. A framework can't not force you to design properly. It can make things easier for you if you design the app properly, however there are always ways around the enforcement of it.

monksy
Can you give me an example? I already use BO and layering technique in my applications. But even so I have seen that it needs a lot of coding to plug my code to new UI technologies.
JMSA
BO? What do you mean by that?
monksy
@Steven - "Business Objects" - but that's a pure stab in the dark
ChrisF
Business Objects. That is table-shadow classes from DB.
JMSA
In the model view controller pattern, the entity (in your case the db shadowed classes) is the model. The model is only responsible for the contents of the data. The controller is repsonsible for only implementing the logic of what is going on between the model and view. The view is only responsible for displaying an interface and sending out messages that an action has been requested. The controller handles the action request and performs the needed actions.
monksy
+4  A: 

To make your code UI independent, put the logic that is not dependent upon UI into a separate layer or assembly. Separate logic from presentation. It's what all the patterns like MVC, MVP, and MVVM follow. It's such a fundamental piece of software structure that it should be ingrained upon you; if it's not, make it so.

Separate logic from presentation. Learn it. Live it. Love it.

Edit:

Can you give me an example? I already use BO and layering technique in my applications. But even so I have seen that it needs a lot of coding to plug my code to new UI technologies.

Please do not provide me with any superficial answer.

I see that you have edited. Allow me to elaborate:

There's no getting away from some logic that is UI-dependent. UIs are not a shell; they still have logic and functionality. But that functionality should only be geared toward user interaction. Display data. Gather data. Fancy graphical tricks and animations, if your preferences lie in that direction.

The rest goes to the business layer, and that stuff can be reused. If you layer properly, you can avoid having to rewrite your core functionality every time you write the program for a new UI framework.

But you still have to rewrite the UI stuff.

Randolpho
+1. And as a general rule, you should never have to import `System.Web` in your business layer or say `System.Data` in your UI layer.
Chetan Sastry
@Chetan Sastry: I agree 90%. For `System.Web` I agree wholeheartedly. `System.Data`, however, contains `DataSet` and `DataTable`, and both are very frequently used in databinding in the UI layer. I personally prefer and recommend POCOs for passing data to the UI layer, but the reality is that there are quite a few folks who still use those two classes. For everything else in the namespace, however, I agree.
Randolpho
Still, good general rule.
Randolpho
+3  A: 

If you're building a multi-tier application, your business logic, data access, etc should already be separated into classes that are completely independent of your UI. Repurposing those libraries for a different target platform - desktop vs web, etc - should be a simple matter of referencing your existing libraries from your new application.

This is a fundamental rule of software development. Although patterns and frameworks like MVC, etc enforce this more stringently, it's ultimately up to you to design your application correctly. This sort of task doesn't require learning a new technology - just common sense and a tiny bit of experience.

David Lively
I already use BO and layering technique in my applications. But even so I have seen that it needs a lot of coding to plug my code to new UI technologies.
JMSA
That "new coding" should be limited to UI-specific behavior. If not, you should reexamine your BO and DAL.
David Lively
+2  A: 

Check out Martin Fowler's excellent article on this topic.

GUI Architectures, Including MVC, MVP, MVPC

Charles Bretana
A: 

Take a look at the explanation of MVVM(Model-View-ViewModel) at MSDN Magazine. MVVM is widely used for WPF application development.

Varuna