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.
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.
Check out Martin Fowler's excellent article on this topic.
GUI Architectures, Including MVC, MVP, MVPC
Take a look at the explanation of MVVM(Model-View-ViewModel) at MSDN Magazine. MVVM is widely used for WPF application development.
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:
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.
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.