I'm new to .NET - what should I concentrate on and what should I ignore?

Good question! I'm assuming that you can pick up the C# syntax as you go so I'll focus on the big picture.

To get started with a WebForms application, you must understand the page lifecycle and the application lifecycle. This is your first priority. The model used by ASP.NET is based on Windows form-based programming and this has implications for how you think about the entire software production process. Now, I'm assuming that you will be building a WebForms application because WebForms technology (in ASP.NET) is more mature, has better third-party support and has far more documentation. If you are inclined to MVC, then just keep in mind that a good design will be one or the other - MVC isn't a part of WebForms, it is an alternative to it.

Next, you have some decisions. Will you be using standard data access (e.g. SQLClient) tools, rolling your own data access layer (or using DAL), or using linq to SQL? I say "decisions" because everyone on the team will have to be together on this one. I heartily recommend building a DAL as you can optimize it for your needs. Linq is nice as well but there are some ominous clouds on the horizon. Coordinate, decide and stay with it.

While not mandatory, you should seriously consider building your Business Logic in a separate Class Library (DLL). Visual Studio / ASP.NET make it trivially easy to create your own Class Library and to fold it into your solution. Learn how to do this and you'll be a better developer for years. People usually argue for this on the basis that it will insulate your UI from your data access. While true, that isn't really the advantage - the advantage comes down the road when you are ready to learn and do Unit testing. Just start out with the assumption that you'll split UI from logic and you'll thank me down the road.

At this point, you can (A) build web pages and (B) show dynamic, database-based content in them. Make sure that you master the GridView and the ObjectDataSource objects used to fill them. Note: the ObjectDataSource is what shuttles data from your Business Class Library to your UI. If you don't use a Business Layer, then you'll use SQLDataSource or LinqDataSource objects to access your data directly from the UI.

Don't be settling on your architecture yet!

You now need to decide whether you want to use Microsoft's WebParts, Login and Navigation components. These lock you in to a specific approach to site navigation, UI, etc. but can save you loads of time if appropriate.

Once you know if you'll be using these and you have had a chance to get used to them, then I would recommend getting familiar with Master Pages. I use them extensively and they are great for standardizing the overall look and feel of the site.

Finally, every professional ASP.NET developer must derive their own Page class (e.g. "MyPageClass") so that they can encapsulate common actions at the Page level. For example, I've built a session management object so that I can access all of my commonly-used session variables in a type-safe manner. The derived page class is responsible for providing the sessionObj instance so that every page can access it without any additional work.

Now you are ready to begin building an enterprise class web app!


Design an application. What you need to know should bubble up to the top fairly quickly.


I would say your list is a pretty good start. In addition, if you are mostly building table-direct apps then I would look at the "Dynamic Data" sample applications in VS2008 SP1 which uses REST. I would tend to stay away from the WebForms model and use ASP.Net MVC. It's better for testing, and cleanly separates business logic from the UI. Also, Linq-to-Sql is a very powerful tool when you know it's limitiions.

I would start by building a sample using ASP.Net MVC and linq-to-sql to get your feet wet. It's fairly easy to get started, and shouldn't take long to learn enough of the basics to make it useful.

The Best way to learn is to do.

As far as "What should I ignore?": .Net Remoting and Web Services. This has been replaced with a much more powerful framework called WCF.