There are countless ways for developing applications using the Microsoft .NET framework. Here are four best practices cherry-picked by a developer with many years of experience creating applications built on .NET.
With a flexible development platform like the Microsoft .NET framework, there are a few key areas where you’ll want to apply best practices. I tapped Rion Williams, a longtime .NET developer, to help explain these areas. They include:
- Coding practices and conventions
- Design and architecture
1. Coding Practices and Conventions
Following best practices when writing code in the Microsoft .NET framework allows you to create consistency and facilitate refactoring and maintenance. You also can avoid errors and exceptions.
Consider naming conventions. They may not affect performance, but they can often directly affect the readability of your code. Using variables with meaningful names can help you infer what is going on.
var carsPassed = 0;
is a clearer than:
var c = 0;
Every developer working with the Microsoft .NET framework has his or her own conventions. But there are some commonly accepted standards around naming, code layout, appearance and the like. The following resources can clue you in to these standards:
- Top 7 Coding Standards and Guideline Documents for C#/.NET Developers
- C# Coding Standards for .NET (PDF)
- Microsoft All-In-One .NET Code Framework
2. Design and Architecture
The biggest reason to incorporate best practices in the design and architecture of apps you create in the Microsoft .NET framework is to avoid errors and costly rewrites.
There are hundreds of patterns out there to help govern the design of your application. You’ve probably heard of design patterns with names like “MVC,” “Gang of Four,” “MVVM,” “Repository,” “Unit-of-Work” and “Singleton,” for example. All of these are widely used and each serves a different purpose. They can be used on their own or in conjunction with other patterns if your application calls for it.
Another common concept within the Microsoft .NET framework is N-Tier, or N-Layer, design. The most common of these for smaller applications is three-tier architecture. If you’re using a three-tier architecture for the first time or want to brush up, check out these resources:
- Three-Tier Web Application Development
- A Simple 3-Tier Layers Application in ASP.NET
- MVC N-Tier EMR Sample
- An N-Tier Architecture Sample With ASP.NET MVC3, WCF and Entity Framework
The following additional resources can help you delve even deeper into different Microsoft .NET framework design and architecture patterns:
- .NET Design Patterns
- Discover the Design Patterns You’re Already Using in the .NET Framework
- ASP.NET Patterns Every Developer Should Know
- Microsoft’s Patterns and Practices Site
Looking for some instant gratification? Pay close attention to Rion’s suggestions for improving performance.
One of the best ways to identify possible areas of improvement is to use an analyzer to take a look at your code (or the Web Requests that are made from your application). Check out these analyzers for the Microsoft .NET framework:
- ReSharper, says Rion, “is the single greatest tool available in the .NET development world.” It provides code suggestions for improvements as you develop your applications. The tool also offers code quality analysis, error elimination and code testing. ReSharper is available for purchase, but you can download a 30-day free trial before you buy.
- EQATEC Profiler is a free tool that identifies areas for improvement and areas of weakness within your code.
Another tool Rion raves about is the Web Developer Checklist, which he describes as an excellent resource for improving web application performance.
Some of the major concerns relating to security within applications built on the Microsoft .NET framework are SQL Injection and XSS (Cross Site Scripting) Injection. These attacks could cripple your data or web application if you aren’t properly protected, Rion says. By default, .NET implements its own measures to help prevent this from happening. But there are additional precautions you should take.
One example, Rion says, is the use of SQL Parameters as opposed to simply concatenating strings when building SQL queries.
If you are calling your Stored Procedure or query through ASP.NET and are simply concatenating the values of something like a TextBox with your SQL call that calls your query, that could make your code susceptible to SQL Injection.
You should always populate any values that are pulled from your application as SQL Parameters to ensure proper encoding. You never want to give users an opportunity to write their own SQL code (or inject it) into one of your queries, Rion cautions.
If Stored Procedures are an option within your Microsoft .NET framework application, consider using them. Stored Procedures are safer than using direct SQL code because they have this same functionality already integrated into them.
Here are some additional resources to learn more about Stored Procedures:
- Do Stored Procedures Prevent SQL Injection?
- How to Prevent SQL Injection in Stored Procedures
- Does Stored Procedures Help Eliminate SQL Injection?
Armed with the Microsoft .NET framework best practices and resources mentioned above, you can develop more consistent, better performing and more secure applications.
Find out starting salaries for .NET developers in your area:
This post has been updated to reflect more current information.