I might be working on an ASP.NET application. What does a Java/PHP developer need to know before starting?_问答_开发者

I am primarily a Java and PHP developer and have some experience with .NET with C# but mostly on t开发者_运维技巧he desktop.

What advice would you give me in starting a new ASP.NET application? What is the best MVC choice? What should I avoid doing? What are the major differences in developing a web app using ASP.NET as opposed to PHP or Java? Are there any conventions that ASP.NET uses that PHP and Java don't?

What are some best practices or things I should avoid doing all together?

Anything you could think of would be a great deal of help.

As a PHP developer, C# syntax will take a bit of getting used to but, as a professional, you shouldn't have any major problems. So, lets focus on the framework.

First, ASP.NET MVC and ASP.NET Webforms are alternative options for architecting a web application in ASP.NET. While MVC is getting a lot of attention (it is the cool option right now - and for some pretty good reasons), don't rule out WebForms until you've had a chance to really compare the two. Also, this is an area where you, as a PHP developer, need to step back a bit. ASP.NET supports some very sophisticated architectural options (more below). PHP apps tend to be designed by just throwing lots of pages together. While you can certainly do things this way in ASP.NET, I wouldn't recommend it since you have better options.

If you'll be using ASP.NET MVC, then you'll need to learn the overall MVC architecture first: the directory structure and rules for coordinating Views and Controllers. Indeed, your biggest challenge is likely to be in just figuring out how the views are "wired up" to the controller. Especially since it is all done by convention - you cannot discover it by looking at the controller - it may take a little while to get used to. The page layout itself will be similar to what you've been doing in PHP in terms of embedding what ASP.NET MVC calls "helpers." You're likely to need a book but, to start, make sure you visit the ASP.NET MVC site from Microsoft and go through the video tutorials. There are a lot of them and they are very good.

You should consider WebForms development as well. It is easier to write a badly architected application (although easy enough to do a good one as well) but it is much easier to pick up and get going with. If you go this route, 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.

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 or LINQ to Entities? 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 to SQL/Entities is nice as well but there are some ominous clouds on the horizon. Coordinate, decide and stay with it.

If going with a WebForms application, you should seriously consider making it more "MVC-like" by 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 (even if you are using MVC). 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.

Another few notes with respect to WebForms (these tools are mostly unavailable to MVC developers - thus my advice above about the speed of getting started):

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!

If you are using webforms, get a book. It's a very different approach to web development than anything else out there. It will hurt your head and you will write terrible code unless you either are trained on it or read a lot about it.

If you are using a stateless model like MVC, the transition will be much smoother as it's closer to what you've already done.

You better start thinking more about forms rather than communication throughout your application using POST/GET.

Look for components into the toolbar - ASP.NET is component-oriented; thus, you will avoid to write content into the page manually, the controls will do it. Make sure you understand ViewState and page's life cycle.