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

Question

So, I've had a fair amount of experience programming database driven web apps using php and coldfusion (not together, at different times) and I'm starting to look into the asp.net world (I have a project coming up at work that is all asp.net/c#.)

My question is: there seems to be a lot of stuff to get mired in and if I'm just making web-based applications (mostly CRUD-type stuff - no mind-bending logic) what are the topics I should be focusing on? I just don't want to go down the rabbit trail of something to find out later that it's not really used too much by the development community. In reading some books (ASP.net 3.5 step by step and ASP.net 3.5 unleashed) I'm finding some area's where a topic will be explained but at the end of the chapter it'll say "this stuff is cool but not for use in multi-tiered applications..."

The topics I've looked at so far (that seem to differ greatly from the applications I'm used to building) are:

• Master pages
• DataBinding
• Linq to SQL
• ASP.NET MVC
• Templates and databinding expressions
• asp.net controls

Scar

Answer 1

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!

Longshore

nice write-up... though i will say that your last point is of less importance beyond ASP.NET 1.0 – Thyroxine

Alex - why do you say that deriving a page class is of less importance? I'm curious! – Longshore

I think master pages made much of the functionality obtained by creating a base page class superfluous. But that's just my 2 cents! – Thyroxine

Alex - I disagree. The point of deriving from a base page class is that you can access variables and utility methods as if they are part of your class. To access variables/methods in a Master Page, you'll need to place a directive in your ASPX page and then reference the Master through a variable. – Longshore

Master pages are just different - great - but different and with a different role than a base page class. – Longshore

Answer 2

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

Ido

I completely agree. build an actual application that does something you need. not just the standard sample app. You then come across the areas you really need to learn. – Judicator

This is the best advice. – Gideon

I agree with the sentiment but there are a few items that you should decide up front (data access layer, use of MS WebParts, use of MVC, etc). I covered them in my response below. – Longshore

Answer 3

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.

Discombobulate

Ignoring .NET Remoting in favour of WCF? – Obvolute

Answer 4

One of the things that you should not forget to review, mainly if you are going to develop a web application, is that you should know the life cycle of a webForm, also you need to be familiar on how the server side works, how the client side works. Then you can review the Master Pages, to have a common look and feel and behavior among your site, asp .net controls, user controls, etc. Generics, anonymous methods, uff there is much more to learn, actually I am trying to learn something new about C# every free time I have... there is much more... :)

Good Luck!!

Benne

"you should know the life cycle of a webForm" unless you do MVC. In fact, a big benefit of MVC is that you don't have to know all that cruft. – Corabelle

Answer 5

If your websites will be very CRUD heavy have a look at Dynamic Data.

If you already have enough knowledge from other platforms I would also have a look at things like viewstate / control state and how they work.

You can reuse most of your knowlegde from other platforms html/javascript. Masterpages are the thing to know and what happens with the page lifecycle when using them.

ORM/SQL injection/input filtering is something you should also get to know by heart.

If you've used MVC frameworks in the past then go with MS MVC if not then you might want to wait till your comfortable with them before digging in.

Vinegarish

Answer 6

Well, to be honest one thing that is really important is to understand what static usage means, and how it affects things around it. If you don't understand concurrency, thread safety and race conditions, don't use static. I only mention this because I've been stuck fixing quite a few bugs the past several months all related to static resources that aren't used properly. This may be considered an advanced topic, but it is very important to understand.

Statuary

Answer 7

1. Study C# first
2. Choose a CRUD object oriented approach: choices are Entity Framework (Microsoft suggested choice), Linq2SQL, Nhibernate (my personal suggestion).
3. ASP.Net MVC+Nunit+JQuery+JSon objects.
   I would also look at WCF as it is becoming more and more important.

Two good starting point for general architecture for web applications and a starting project are :

• Application Arch Guide
• S#arp Architecture

Sarchet

Answer 8

I'd start with the basics first. There are a lot of powerful controls and 'widgets' in ASP.NET 2.0 and and 3.5, especially with the AJAX controls, but I found it confusing to try and sort all of those out without first having an understanding of, as you said' basic CRUD web pages' in ASP.NET - which is what most real projects will come down to anyway.

Most of the problems and hard to track down bugs I've had to deal with in .NET web programming came down to me not fully understanding the ASP.NET basics like PostBack, ViewState, Refresh, and ASP.NET databinding (the basic handcoded method, not the fancy no-code grid stuff in 2.0) - once you understand that stuff, the master pages, themes and AJAX stuff is pretty easy.

I'd recommend Wrox Press ASP.NET 2.0, or Professional C# 2008

Flinger

Great point - I think the hardest time I'm having is with the whole Viewstate idea - it's just totally unlike anything I've ever done. Thanks! – Gustin