Why Use Code Behind?
There are many .NET developers across the full range of skill levels that are using code behind for the logic of their C# or VB.NET applications, not just for UI management.
This post looks at the possible reasons for this. It would be great to get your thoughts on this topic. (Use the comments section below so the conversation is visible to everyone.)
NOTE: Depending on your UI technology, it makes sense to put code that manages the UI into the code behind. However, there are many alternate places to put the logic of the application.
From what I have seen, using code behind for all application logic normally stems from one (or a combination) of the following:
- Quick and Easy
- Work Environment: Management
- Work Environment: Work Space
- Minimum Viable Product
Quick and Easy
If a developer needs to build a quick application for the support staff to update customer types or view log transactions, that developer wants to spend the least amount of time possible. There are other things that directly affect the customers that are much more important to spend time on.
Using code behind is quick and easy. Just double-click on a UI element in a Visual Studio designer, write code, and run. It’s done!
By their very nature, the Visual Studio designers are set up for code behind. And many Visual Studio demonstrations show off the cool designer tooling.
New .NET developers often learn to program using these designers with code behind. And even as they progress with their knowledge and tackle more complex applications, they never get out of the "double-click and write code" habit.
Work Environment: Management
Maybe the manager is not technical or has not kept up with current software development life cycle (SDLC) techniques. Or maybe the manager has seen one too many Visual Studio "double-click and write code" demonstrations and has seen how "fast" developers can write code.
In either case, they may only be focused on getting features out quickly. If so, developers may feel that code behind is all they can do in the time allocated.
Work Environment: Work Space
Do the developers work in an office with constant interruptions? Do they get a "ping" every time they get a new email, Facebook post, or tweet? Do they have to provide immediate customer support? Do they work at home in the family room with the kids asking for homework help and the significant other watching TV?
Developing an application using only code behind often requires much less concentration. Just double-click to write the code, double-click to open the code … and the code is all there.
Building applications that use components, base classes, inversion of control, services, patterns, and so on require significantly more thinking. And as such, are very challenging to work with in an interrupt-drive environment.
See this post for some interesting information on software developer interruptions.
Minimum Viable Product
Minimum viable product is a agile strategy that focuses on getting the minimum set of software features in place to allow the product to be deployed and nothing more. The customers can then provide feedback and the software can be refactored and adjusted as necessary.
Depending on the selected technologies, using code behind for all of the application logic may be the quickest way to a minimum viable product. Refactoring to components, interfaces, and other technologies come later.
Are there other reasons? Your thoughts?