The seven pillars of aspnet
Upcoming SlideShare
Loading in...5
×
 

The seven pillars of aspnet

on

  • 2,389 views

This document provides information regarding to asp.net

This document provides information regarding to asp.net

Statistics

Views

Total Views
2,389
Views on SlideShare
2,389
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The seven pillars of aspnet The seven pillars of aspnet Document Transcript

  • The Seven Pillars of ASP.NETWhen ASP.NET was first released, there were seven key facts that differentiated it from previousMicrosoft products and competing platforms. If you’re coming to ASP.NET from another webdevelopment platform, or you’re an old-hand .NET coder who has yet to try programming for the Web,these sections will quickly give you a bit of ASP.NET insight.#1: ASP.NET is integrated with the .NET FrameworkThe .NET Framework is divided into an almost painstaking collection of functional parts, with tens ofthousands of types (the .NET term for classes, structures, interfaces, and other core programmingingredients). Before you can program any sort of .NET application, you need a basic understanding ofthose parts—and an understanding of why things are organized the way they are. The massive collectionof functionality that the .NET Framework provides is organized in a way that traditional Windowsprogrammers will see as a happy improvement. Each one of the thousands of classes in the .NETFramework is grouped into a logical, hierarchical container called a namespace. Different namespacesprovide different features. Taken together, the .NET namespaces offer functionality for nearly everyaspect of distributed development from message queuing to security. This massive toolkit is called theclass library.Interestingly, the way you use the .NET Framework classes in ASP.NET is the same as the way you usethem in any other type of .NET application (including a stand-alone Windows application, a Windowsservice, a command-line utility, and so on). Although there are Windows-specific and web-specificclasses for building user interfaces, the vast majority of the .NET Framework (including everything fromdatabase access to multithreaded programming) is usable in any type of application. In other words,.NET gives the same tools to web developers that it gives to rich client developers.■ Tip: One of the best resources for learning about new corners of the .NET Framework is the .NETFramework class library reference, which is part of the MSDN Help library reference. If you have VisualStudio 2008 installed, you can view the MSDN Help library by clicking the Start button and choosingPrograms ➤ Microsoft Visual Studio 2010 ➤ Microsoft Visual Studio 2010 Documentation (the exactshortcut depends on your version of Visual Studio). Or, you can find the most recent version of the classlibrary reference online athttp://tinyurl.com/2d42w5e.#2: ASP.NET Is Compiled, Not InterpretedASP.NET applications, like all .NET applications, are always compiled. In fact, it’s impossible to executeC# or Visual Basic code without it being compiled first..NET applications actually go through two stages of compilation. In the first stage, the C# code you writeis compiled into an intermediate language called Microsoft Intermediate Language (MSIL), or just IL. Thisfirst step is the fundamental reason that .NET can be language-interdependent. Essentially, all .NETlanguages (including C#, Visual Basic, and many more) are compiled into virtually identical IL code. Thisfirst compilation step may happen automatically when the page is first requested, or you can perform itin advance (a process known as pre-compiling). The compiled file with IL code is an assembly.
  • The second level of compilation happens just before the page is actually executed. At this point, the ILcode is compiled into low-level native machine code. This stage is known as just-in-time (JIT)compilation, and it takes place in the same way for all .NET applications (including Windowsapplications, for example). Figure 1-1 shows this two-step compilation process..NET compilation is decoupled into two steps in order to offer developers the most convenience and thebest portability. Before a compiler can create low-level machine code, it needs to know what type ofoperating system and hardware platform the application will run on (for example, 32-bit or 64-bitWindows). By having two compile stages, you can create a compiled assembly with .NET code and stilldistribute this to more than one platform.Of course, JIT compilation probably wouldn’t be that useful if it needed to be performed every time auser requested a web page from your site. Fortunately, ASP.NET applications don’t need to be compiledevery time a web page is requested. Instead, the IL code is created once and regenerated only when the
  • source is modified. Similarly, the native machine code files are cached in a system directory that has apath like c:WindowsMicrosoft.NETFramework[Version]Temporary ASP.NET Files.The actual point where your code is compiled to IL depends on how you’re creating and deploying yourweb application. If you’re building a web project in Visual Studio, the code is compiled to IL when youcompile your project. But if you’re building a lighter-weight project less website, the code for each pageis compiled the first time you request that page. Either way, the code goes through its secondcompilation step (from IL to machine code) the first time it’s executed.ASP.NET also includes pre-compilation tools that you can use to compile your application right down tomachine code once you’ve deployed it to the production web server. This allows you to avoid theoverhead of first-time compilation when you deploy a finished application (and prevent other peoplefrom tampering with your code).#3: ASP.NET Is MultilanguageThough you’ll probably opt to use one language over another when you develop an application, thatchoice won’t determine what you can accomplish with your web applications. That’s because no matterwhat language you use, the code is compiled into IL.IL is a stepping stone for every managed application. (A managed application is any application that’swritten for .NET and executes inside the managed environment of the CLR.) In a sense, IL is the languageof .NET, and it’s the only language that the CLR recognizes.To understand IL, it helps to consider a simple example. Take a look at this code written in C#:using System;namespace HelloWorld{public class TestClass{static void Main(string[] args){Console.WriteLine("Hello World");}}}This code shows the most basic application that’s possible in .NET—a simple command-line utility thatdisplays a single, predictable message on the console window. Now look at it from a differentperspective. Here’s the IL code for the Main() method:.method private hidebysig static void Main(string[] args) cil managed{.entrypoint// Code size 13 (0xd).maxstack 8IL_0000: nop
  • IL_0001: ldstr "Hello World"IL_0006: call void [mscorlib]System.Console::WriteLine(string)IL_000b: nopIL_000c: ret} // end of method TestClass::MainIt’s easy enough to look at the IL for any compiled .NET application. You simply need to run the ILDisassembler, which is installed with Visual Studio and the .NET SDK (software development kit). Lookfor the file ildasm.exe in a directory like c:Program FilesMicrosoft SDKsWindowsv7.0Abin. Runildasm.exe, and then use the File ➤ Open command, and select any DLL or EXE that was created with.NET.■ Tip: For even more disassembling power, check out the remarkable (and free) Reflector tool athttp://www.red-gate.com/products/reflector. With the help of community-created add-ins, you can useReflector to diagram, analyze, and decompile the IL code in any assembly.If you’re patient and a little logical, you can deconstruct the IL code fairly easily and figure out what’shappening. The fact that IL is so easy to disassemble can raise privacy and code control issues, but theseissues usually aren’t of any concern to ASP.NET developers. That’s because all ASP.NET code is storedand executed on the server. Because the client never receives the compiled code file, the client has noopportunity to decompile it. If it is a concern, consider using an obfuscator that scrambles code to try tomake it more difficult to understand. (For example, an obfuscator might rename all variables to havegeneric, meaningless names such as f__a__234.) Visual Studio includes a scaled-down version of onepopular obfuscator, called Dotfuscator.The following code shows the same console application in Visual Basic code:Imports SystemNamespace HelloWorldPublic Class TestClassShared Sub Main(args() As String)Console.WriteLine("Hello World")End SubEnd ClassEnd NamespaceIf you compile this application and look at the IL code, you’ll find that it’s nearly identical to the IL codegenerated from the C# version. Although different compilers can sometimes introduce their ownoptimizations, as a general rule of thumb no .NET language outperforms any other .NET language,because they all share the same common infrastructure. This infrastructure is formalized in the CLS(Common Language Specification), which is described in the following sidebar, entitled “The CommonLanguage Specification.” It’s worth noting that IL has been adopted as an Ecma and ISO standard. This adoption allows theadoption of other common language frameworks on other platforms. The Mono project athttp://www.mono-project.com is the best example of such a project.The Common Language Specification
  • The Common Language SpecificationThe CLR expects all objects to adhere to a specific set of rules so that they can interact. The CLS is this setof rules.The CLS defines many laws that all languages must follow, such as primitive types, method overloading,and so on. Any compiler that generates IL code to be executed in the CLR must adhere to all rulesgoverned within the CLS. The CLS gives developers, vendors, and software manufacturers the opportunityto work within a common set of specifications for languages, compilers, and data types. You can find alist of a large number of CLS-compliant languages at http://dotnetpowered.com/languages.aspx.Given these criteria, the creation of a language compiler that generates true CLR-compliant code can becomplex. Nevertheless, compilers can exist for virtually any language, and chances are that there mayeventually be one for just about every language you’d ever want to use. Imagine—mainframeprogrammers who loved COBOL in its heyday can now use their knowledge base to create webapplications!#4: ASP.NET Is Hosted by the Common Language RuntimePerhaps the most important aspect of the ASP.NET engine is that it runs inside the runtime environmentof the CLR. The whole of the .NET Framework—that is, all namespaces, applications, and classes—isreferred to as managed code. Though a full-blown investigation of the CLR is beyond the scope of thischapter, some of the benefits are as follows:Automatic memory management and garbage collection: Every time your application instantiates areference-type object, the CLR allocates space on the managed heap for that object. However, younever need to clear this memory manually. As soon as your reference to an object goes out of scope (oryour application ends), the object becomes available for garbage collection. The garbage collector runsperiodically inside the CLR, automatically reclaiming unused memory for inaccessible objects. This modelsaves you from the low-level complexities of C++ memory handling and from the quirkiness of COMreference counting.Type safety: When you compile an application, .NET adds information to your assembly that indicatesdetails such as the available classes, their members, their data types, and so on. As a result, otherapplications can use them without requiring additional support files, and the compiler can verify thatevery call is valid at runtime. This extra layer of safety completely obliterates whole categories of low-level errors.Extensible metadata: The information about classes and members is only one of the types of metadatathat .NET stores in a compiled assembly. Metadata describes your code and allows you to provideadditional information to the runtime or other services. For example, this metadata might tell adebugger how to trace your code, or it might tell Visual Studio how to display a custom control at designtime. You could also use metadata to enable other runtime services, such as transactions or objectpooling.Structured error handling: .NET languages offer structured exception handling, which allows you toorganize your error-handling code logically and concisely. You can create separate blocks to deal withdifferent types of errors. You can also nest exception handlers multiple layers deep.Multithreading: The CLR provides a pool of threads that various classes can use. For example, you cancall methods, read files, or communicate with web services asynchronously, without needing toexplicitly create new threads.
  • #5: ASP.NET Is Object-OrientedASP provides a relatively feeble object model. It provides a small set of objects; these objects are reallyjust a thin layer over the raw details of HTTP and HTML. On the other hand, ASP.NET is truly objectoriented. Not only does your code have full access to all objects in the .NET Framework, but you can alsoexploit all the conventions of an OOP (object-oriented programming) environment. For example, youcan create reusable classes, standardize code with interfaces, extend existing classes with inheritance,and bundle useful functionality in a distributable, compiled component.One of the best examples of object-oriented thinking in ASP.NET is found in server-based controls.Server-based controls are the epitome of encapsulation. Developers can manipulate control objectsprogrammatically using code to customize their appearance, provide data to display, and even react toevents. The low-level HTML markup that these controls render is hidden away behind the scenes.
  • Instead of forcing the developer to write raw HTML manually, the control objects render themselves toHTML just before the web server sends the page to the client. In this way, ASP.NET offers server controlsas a way to abstract the low-level details of HTML and HTTP programming.Here’s a quick example with a standard HTML text box that you can define in an ASP.NET web page: <input type="text" id="myText" runat="server" />With the addition of the runat="server" attribute, this static piece of HTML becomes a fully functionalserver-side control that you can manipulate in C# code. You can now work with events that it generates,set attributes, and bind it to a data source. For example, you can set the text of this box when the pagefirst loads using the following C# code:void Page_Load(object sender, EventArgs e){myText.Value = "Hello World!";}Technically, this code sets the Value property of an HtmlInputText object. The end result is that a stringof text appears in a text box on the HTML page that’s rendered and sent to the client. HTML Controls VS. Web ControlsWhen ASP.NET was first created, two schools of thought existed. Some ASP.NET developers were mostinterested in server-side controls that matched the existing set of HTML controls exactly. This approachallows you to create ASP.NET web-page interfaces in dedicated HTML editors, and it provides a quickmigration path for existing ASP pages. However, another set of ASP.NET developers saw the promise ofsomething more—rich server-side controls that didn’t just emulate individual HTML tags. These controlsmight render their interface from dozens of distinct HTML elements while still providing a simpleobjectbased interface to the programmer. Using this model, developers could work with programmablemenus, calendars, data lists, validators, and so on.After some deliberation, Microsoft decided to provide both models. You’ve already seen an example ofHTML server controls, which map directly to the basic set of HTML tags. Along with these are ASP.NETweb controls, which provide a higher level of abstraction and more functionality. In most cases, you’lluse HTML server-side controls for backward compatibility and quick migration, and use web controls fornew projects.ASP.NET web control tags always start with the prefix asp: followed by the class name. For example, thefollowing snippet creates a text box and a check box:<asp:TextBox id="myASPText" Text="Hello ASP.NET TextBox" runat="server" /><asp:CheckBox id="myASPCheck" Text="My CheckBox" runat="server" />Again, you can interact with these controls in your code, as follows:myASPText.Text = "New text";myASPCheck.Text = "Check me!";Notice that the Value property you saw with the HTML control has been replaced with a Text property.The HtmlInputText.Value property was named to match the underlying value attribute in the HTML
  • <input> tag. However, web controls don’t place the same emphasis on correlating with HTML syntax, sothe more descriptive property name Text is used instead.The ASP.NET family of web controls includes complex rendered controls (such as the Calendar andTreeView), along with more streamlined controls (such as TextBox, Label, and Button), which mapclosely to existing HTML tags. In the latter case, the HTML server-side control and the ASP.NET webcontrol variants provide similar functionality, although the web controls tend to expose a morestandardized, streamlined interface. This makes the web controls easy to learn, and it also meansthey’re a natural fit for Windows developers moving to the world of the Web, because many of theproperty names are similar to the corresponding Windows controls.#6: ASP.NET supports all BrowsersOne of the greatest challenges web developers face is the wide variety of browsers they need tosupport. Different browsers, versions, and configurations differ in their support of XHTML, CSS, andJavaScript. Web developers need to choose whether they should render their content according to thelowest common denominator, and whether they should add ugly hacks to deal with well-known quirkson popular browsers.ASP.NET addresses this problem in a remarkably intelligent way. Although you can retrieve informationabout the client browser and its capabilities in an ASP.NET page, ASP.NET actually encouragesdevelopers to ignore these considerations and use a rich suite of web server controls. These servercontrols render their markup adaptively by taking the client’s capabilities into account. One example isASP.NET’s validation controls, which use JavaScript and DHTML (Dynamic HTML) to enhance theirbehavior if the client supports it. Another example is the set of Ajax-enabled controls, which usescomplex JavaScript routines that test browser versions and use carefully tested workarounds to ensureconsistent behavior. These features are optional, but they demonstrate how intelligent controls canmake the most of cutting-edge browsers without shutting out other clients. Best of all, you don’t needany extra coding work to support both types of client.#7: ASP.NET Is Easy to Deploy and ConfigureOne of the biggest headaches a web developer faces during a development cycle is deploying acompleted application to a production server. Not only do the web-page files, databases, andcomponents need to be transferred, but components need to be registered and a slew of configurationsettings need to be re-created. ASP.NET simplifies this process considerably.Every installation of the .NET Framework provides the same core classes. As a result, deploying anASP.NET application is relatively simple. For no-frills deployment, you simply need to copy all the files toa virtual directory on a production server (using an FTP program or even a command-line command likeXCOPY). As long as the host machine has the .NET Framework, there are no time-consuming registrationsteps. Chapter 18 covers deployment in detail.Distributing the components your application uses is just as easy. All you need to do is copy thecomponent assemblies along with your website files when you deploy your web application. Because allthe information about your component is stored directly in the assembly file metadata, there’s no needto launch a registration program or modify the Windows registry. As long as you place these
  • components in the correct place (the Bin subdirectory of the web application directory), the ASP.NETengine automatically detects them and makes them available to your web-page code. Try that with atraditional COM component!Configuration is another challenge with application deployment, particularly if you need to transfersecurity information such as user accounts and user privileges. ASP.NET makes this deployment processeasier by minimizing the dependence on settings in IIS (Internet Information Services). Instead, mostASP.NET settings are stored in a dedicated web.config file. The web.config file is placed in the samedirectory as your web pages. It contains a hierarchical grouping of application settings stored in an easilyreadable XML format that you can edit using nothing more than a text editor such as Notepad. Whenyou modify an application setting, ASP.NET notices that change and smoothly restarts the application ina new application domain (keeping the existing application domain alive long enough to finishprocessing any outstanding requests). The web.config file is never locked, so it can be updated at anytime.