The advantages of asp.net2.0+vs2005 sharp Weapon analysis

asp.net

asp.net 2.0 and Visual Studio 2005 have been officially listed for several months now. As time goes on, more and more people are now able to use this product. Based on the trial of this product, the author tries to analyze the advantages and disadvantages of this product from a personal point of view, for reference only.

　　 first, the introduction

To be honest, my relationship with ASP.net 2.0 and Visual Studio 2005 is somewhat like and annoying, but I finally decided to migrate most of my internal applications to 2.0 and never regret it. Basically, there are so many new features in ASP.net 2.0 that make my life easier and never return to programming in the previous 1.1 version.

So far, the platform has been working well. I've found that many of the improvements that exist can significantly reduce the complexity and number of encodings, increase 10~20% in performance, and reduce memory requirements (which is important for large applications), but have little effect on my work.

Adding 2.0 features to an existing application is definitely not an overnight event. However, as I gradually became accustomed to quickly adding a large number of 2.0 features to my new application, my final feeling was that it would be a big step back if you returned to ASP.net 1.1 and vs 2003.

　　 second, the evaluation of the advantages

Now, let's take a look at the main changes in this new product and see its advantages first.

(i) Visual Studio 2005 File-based Engineering Development

Now, in Visual Studio 2005, you can open a directory as a Web project, which is a pretty good improvement. On my development machine, I might have 50 different Web projects. Using the previous VS2003, it is quite a headache to configure and maintain all of these as virtual directories in IIS and to properly reference the engineering implementation. Don't you think so? Do you want to move some projects to a new machine? In VS2005, you simply point to a directory to open the project. You can use a local Web server build method to run your application so that you don't have to configure your Web server.

This feature is especially useful for developers sharing the sample-any developer who wants to examine a sample Web application does not have to undergo the pain of configuring based on IIS. Now, with file-based engineering, you can--at least at the development site--achieve a true "xCopy" project. This is a great feature, but it is not without drawbacks (we will be able to detail it later).

"Note" Everyone I touch likes to build a Cassini Web server inside Visual Studio. Of course, I also like it, because it greatly simplifies the handling of many problems. However, there are some drawbacks to its use. It is important to avoid mutual interference between Cassini and IIS during the course of use. For example, Cassini can pass all requests to the asp.net and ignore the extended content. If you have a custom processor that handles a particular file type (for example, building Excel reports dynamically, and so on, you have to remember that when you publish your application, you have to create a custom mapping for the extended content in IIS, otherwise IIS will not pass the request to ASP.net. I have contacted many friends to spend a lot of time at publishing to solve problems in their applications because they never worry about configuration settings in Cassini during the development process.

(ii) Master pages

Now you can define a master page template that can be reused in your application. Use this feature to save you a lot of development time. In fact, before the 2.0 release, there was already a concept based on the ASP.net 1.x version, but for me, the most critical feature that attracted me was that Visual Studio provided visual support for it. This allows you to see the layout of the master, where contentplaceholders can be applied to each page to provide page-level content.

In addition to the important visual aspects that the designer provides, the master page template provides a good way to connect reusable code that is related to each other. The purpose of a master page is to incorporate functionality that previously required the use of several user controls, such as Header,footer and sidebar, to enable them to achieve logical separation more effectively than before.

You can also change the master page dynamically at run time to achieve greater flexibility. This support enables users to change the overall look and feel of an application, and this effect is not possible only by switching cascading style tables.

(iii) Visual description of user controls

To be honest, I really want to be able to see the whole page when I design it. Like a master page, Visual Studio 2005 now has the ability to display a generated user control within the Web Forms editor. Instead of a previous old-fashioned, descriptive gray box with a control name, you can now get a fully-generated, properly-built control within the designer. Double-click it, then vs will navigate you to the user control designer. In my development, I don't typically use a lot of user controls, I use master pages to replace many of my existing controls, but I find that this kind of user control visualization describes the design pattern more useful. This is especially true for my existing 1.1 version of the application-these controls are often used in my programs to express page headers, sidebars, and footers.

The "Extra note" completely automates the generation of user controls greatly saves development time. Of course, I also need to spend a lot of time switching back and forth from the IDE to a browser to see how the user control will eventually be generated. That's all.

(iv) generic

Yes, this is not a asp.net-specific feature, but the introduction of generics in. NET 2.0 greatly enriches code writing. In the past, I used to be very cautious when creating custom collections, and frankly, it was a very torturous task to derive from CollectionBase and then implement the same code again and again. For custom control development, especially in asp.net, I've found that using a generic collection is pretty good when you need a collection feature.

You simply use a list or a specific generic collection and then take it as a property of the control-the problem is simple! Visual Studio can see the collection and, in most cases, it can also provide you with the appropriate collection editor. By using a generic list, you can easily use a strongly typed list instead of many ArrayList lists, which often makes coding clearer.

Finally, using dynamic type substitution within a business object eliminates the need for a "scary" initialization encoding (previously, in every business object, this initialization is required to specify which entity type is associated with it). Before generics occur, it is often necessary to use a small coding agent to bind business objects and entities together. Now that you have a generic type, you no longer need such an encoding, but instead a generic type parameter. Thereafter, all class-level code can use the generic class description to automatically generate the correct type at run time. With a typed parameter and a set of parent-class methods, there is no need to cut and paste a large amount of code from all of my business objects anymore. In fact, there are many places where generics are used, and today I find it difficult to do many things without using generic types, especially when dealing with collection-related content.

The "Extra note" generics will be widely used in collections and business object operations, and you can benefit from the page base class and user control development. Recently, I saw someone on the Web build a generic base page implementation that automatically loads business object data and creates corresponding AJAX callback mechanisms to update these objects. You see, the things that have been so frustrating in every new page have become so easy!

(v) Support for embedded resources

I prefer to use a lot of custom controls in my own application. Often, these controls depend on specific resources, such as images, CSS files, XML resources, and so on. At this point, users of any of these controls must remember to publish the appropriate files in their applications. Today, in asp.net development, you can easily embed the Web resources you need into a project and then access them via a asp.net generating dynamic URLs. To do this, you simply add the [WebResource] attribute to your control's AssemblyInfo file, and then use PAGE.CLIENTSCRIPT.GETWEBRESOURCEURL to retrieve the URL that contains the resource's contents.

(vi) Visual studioasp.net Code Editor

The Visual Studio 2005 Code Editor is a big step ahead of the 2003 version. I think the most important new "feature" is that the new editor does not automatically "disrupt" My Code format unless I reformat the document. For example, I want my content to be organized the way I like it, however, when I use VS2003 it becomes a problem--whenever you add a new control to the page system, it will reformat the HTML. In VS2005, the editor retains the user's own code format in most cases, and provides a better handle-inserting the control tag into the code.

A real improvement in productivity is the introduction of IntelliSense technology into the new HTML editor-and everywhere! I often embed <%=%> expressions inside a page, and IntelliSense means it helps me avoid typos. ASP.net 2.0 also compiles the page and examines the generated embedded scripting code so that errors in the HTML markup are captured early at design time rather than at run time.
IntelliSense is appropriate for all controls, including your own custom controls, so you don't have to provide a private type schema file anymore. Visual Studio can simply find your controls and manage IntelliSense internally. IntelliSense support is great, and sometimes it can even "go beyond" the visual designer. After a while, you will understand why this may be more important than you think.

As a novice who has recently transferred from Visual Basic to C #, I particularly appreciate the C # IntelliSense support provided by Visual Studio 2005. In previous versions of Visual Studio there was a significant gap between IntelliSense support for VB and C #, and when I analyzed C # code, I often found myself needing a VB-style IntelliSense help. Now the gap is gone, and the switch between languages is much easier.