Database Support -Server Side State Management

        This way of maintaining state is mainly used when we need to store large amounts of information, transactions data over the long period of time or required to preserved /survive the application and session restarts means data that persist over the multiple sessions. This type also provides us the security of state information as it is stored in database as there is a facility for security at web server also authentication & authorization mechanism is provided. As there are many security layers involved and we are storing into the database it is slower than any other state management options present. The data which is stored can be used afterwards as for Data mining.Database support is used in conjunction with cookies or session state

Advantages:

• Storage: No limit on how much data need to be stored.
• Security: Access to DB is through Authentication &Authorization.
• Data Persistency: Data is persistent for as much as time as we want.
• Robustness and data integrity: Databases include various facilities for maintaining good data, including triggers and referential integrity, transactions, and so on. By keeping information about transactions in a database (rather than in session state, for example), you can recover from errors more readily.
• Accessibility: The data stored in your database is accessible to a wide variety of information-processing tools, Data is used for Data Mining purpose. Also there are many database tools are available with different configuration.

Disadvantages:

• Complex Nature: As there are many security layers involved and we are storing into the database it is very much slower than any other state management options present.

Application state-Server Side State Management

    Application state is used to store data on the application machine. Application variable is an object that is shared by the multiple sessions. We can use application variable within page, Http Handler and Global.asax.

     When request a page from client machine, an instance will create at application machine by the help of Http Application State class. Entire application will have only one instance which is provided by Http Context property named Application.    

Implementation of Application State:

  1) Inside the Global.asax page

   

   void Application_Start(object sender, EventArgs e)

     {

       // Code that runs on application startup

       Application["LoginID"] ="xyz";

       Application["DomainName"] = "www.xyz.com";

      }

  

  2) Inside the .aspx page

   Protected void Page_Load (object sender, EventArgs e)

    {

        // Code that runs on page load

        Application ["LoginID"] = "xyz";

        Application ["DomainName"] = "www.xyz.com";

    }

Application state retrieval:

    string loginID=string.Empty;

    LoginID = Application ["LoginID"].ToString ();

    String loginID = string.Empty;

    LoginID = Application.GetKey (0);

    We can retrieve all application variables on the currently running application's keys by

Using Http application State class.

    HttpApplicationState appState = null;

    appState = Application.Contents;

    String [] StateVars = new String [appState.Count];

    StateVars = appState.AllKeys;

Remove Application State:

   We have three methods to remove application variable from the ASP.NET application.

   Application.Remove("LoginID");

   Application.RemoveAt(0);

   Application.RemoveAll();

Implementing Synchronization in application state

   we can avoid deadlock occurenece while we are updating application variable is used by multiples users with help of lock()  and unlock()

   

      Application.Lock(); 

      Application ["LoginID"] = "xyz";

      Application ["DomainName"] = "www.xyz.com";

      Application.UnLock();

Uses of Application State:   

•      Application object memory released when we removed.
•         Multi user can able to access application variable.
•      To avoid deadlock or conflict we should use Lock and Unlock when we use write or update in the application object.
•        Other application can't access this application values.

Dis Advantages of Application State: 

•  Application variable will exists until exit our application.
•  If we do not have Lock() and Unlock, deadlock will occur.
•  Its global variable so anyone can access within this application.
•  Other application can't access this application values.

Sql Server Provider-Profiles

   The ASP.NET profile feature uses the same provider-based structure used by ASP.NET membership, ASP.NET role management, and other ASP.NET features.

    The ASP.NET profile feature works as a tiered system in which the functionality of the profile feature—providing typed property values and managing user identities—is separated from the underlying data storage. The profile feature relies on profile providers (data providers) to perform the back-end tasks required to store and retrieve profile property values.

Default Profile Provider:

   ASP.NET includes a profile provider that stores data using Microsoft SQL Server.The default ASP.NET machine configuration contains a default Sql Profile Provider instance named Asp.Net Sql Profile Provider that connects to SQL Server on the local machine. By default, the ASP.NET profile feature uses this instance of the provider. Alternatively, you can specify a different default provider in your application's Web.config file.

    To use a Sql Profile Provider, you must first create the SQL Server database used by the Sql Profile Provider. You can create the database by running the Aspnet_regsql.exe command, which is found in the following path:

    systemroot\Microsoft .NET\SDK\version

   When you run the tool, you specify the -Ap option. The following command shows the syntax that you use to create the database required to store ASP.NET profiles using the Sql Profile Provider:

    aspnet_regsql.exe–Ap 

  The example above does not specify a name for the database that is created, so the default name will be used. 

  If the profile provider is configured with a connection string that uses integrated security, the process account of the ASP.NET application must have rights to connect to the SQL Server database.

 Note:

  If you are using a SQL Server 2005 Express Edition database that is installed using the default configuration and the database is on the same computer as the Web server, the profile database will be created automatically by ASP.NET.

Custom Profile Providers:

  In some cases, you might want to create and use a custom profile provider. This is often true if you already have a database that stores user information, such as an employee database, if you need to use a database other than Microsoft SQL Server, or if you need to use a different data store, such as XML files.

  The properties stored in a user profile can all be served by different profile providers. You can therefore manage data from multiple data sources to store information for a single user profile.

Note:

    With a Website project you automatically get a class called Profile Common (in the App_Code folder) that wraps up the get/set code for any properties you add to the Profile. Everything is done for you, and you can stop thinking.  

Profiles -Server Side State Management

         

        The ASP.NET profile feature associates information with an individual user and stores the information in a persistent format. Profiles allow you to manage user information without requiring you to create and maintain your own database. In addition, the ASP.NET profile feature makes the user information available using a strongly typed API that you can access from anywhere in your application.You can store objects of any type using profiles. The profile feature provides a generic storage feature that allows you to define and maintain almost any kind of data while still making the data available in a type-safe manner.

Implementation of Profiles:

      To use profiles, you first enable profiles by modifying the configuration file for your ASP.NET Web application. As part of the configuration, you specify a profile provider, which is the underlying class that performs the low-level tasks of storing and retrieving profile data. You can use the profile provider included with the .NET Framework, which stores profile data in SQL Server, or you can create and use your own profile provider as described in the topic implementing a Profile Provider. You can specify an instance of the Sql Profile Provider that connects to a database of your choosing, or you can use the default instance of the Sql Profile Provider that stores profile data on the local Web server.You configure the profile feature by defining a list of properties whose values you want to maintain.

    For an instance, you might want to store the user’s Zip code so that your application can offer region-specific information, such as weather reports. In the configuration file, you would define a profile property named Zip Code. The profile section of the configuration file might look like the following:

<Profile>

  <Properties>

    <add name="Zip Code" />

  </properties>

</profile>

   When your application runs, ASP.NET creates a Profile Common class, which is a dynamically generated class that inherits the Profile Base class. The dynamic Profile Common class includes properties created from the profile property definitions you specify in your application configuration. An instance of this dynamic Profile Common class is then set as the value of the Profile property of the current Http Context and is available to pages in your application.

    In your application, you collect the value or values you want to store and assign them to the profile properties you have defined. For example, your application's home page might contain a text box that prompts the user to enter a postal code. When the user enters a postal code, you set a Profile property to store the value for the current user, as in the following example:

    profile.zipcode=txtzipcode.text

    When you set a value for Profile.ZipCode, the value is automatically stored for the current user. You do not need to write any code to determine who the current user is or explicitly store the value in a database—the profile feature performs these tasks for you.

When you want to use the value, you can get it in much the same way that you set it. For example, the following code example shows how to call an imaginary function named Get Weather Info, passing it the current user's postal code as stored in a profile:

   weather Info = GetWeatherInfo( Profile.ZipCode )

   You do not need to explicitly determine who the user is or perform any database look ups  Simply getting the property value out of a profile causes ASP.NET to perform the necessary actions to identify the current user and look up the value in the persistent profile store.

   

Just-in-time Compiler

         JIT compilation converts MSIL to native code on demand at application run time, when the contents of an assembly are loaded and executed. Because the common language runtime supplies a JIT compiler for each supported CPU architecture, developers can build a set of MSIL assemblies that can be JIT-compiled and run on different computers with different machine architectures. However, your managed code will run only on a specific operating system if it calls platform-specific native APIs, or a platform-specific class library.

         JIT compilation takes into account the fact that some code might never get called during execution. Rather than using time and memory to convert all the MSIL in a portable executable (PE) file to native code, it converts the MSIL as needed during execution and stores the resulting native code in memory so that it is accessible for subsequent calls in the context of that process.

         The loader creates and attaches a stub to each method in a type when the type is loaded and initialized. When a method is called for the first time, the stub passes control to the JIT compiler, which converts the MSIL for that method into native code and modifies the stub to point directly to the generated native code. Subsequent calls to the JIT-compiled method therefore proceed directly to the native code

Common Type System

       The Common Type System defines how types are declared, used, and managed in the common language runtime, and is also an important part of the runtime's support for cross-language integration.    

  The common type system performs the following functions:

•  Establishes a framework that helps enable cross-language integration, type safety, and high-performance code execution.
•  Provides an object-oriented model that supports the complete implementation of many programming languages.
•  Defines rules that languages must follow, which helps ensure that objects written in different languages can interact with each other.
•  Provides a library that contains the primitive data types (such as Boolean, Byte, Char, Int32, and UInt64) used in application development.
• The CTS also specifies the rules for type visibility and access to the members of a type, i.e. the CTS establishes the rules by which assemblies form scope for a type, and the Common Language Runtime enforces the visibility rules.
• The CTS defines the rules governing type inheritance, virtual methods and object lifetime. 
• The common type system supports two general categories of types:
• Value types:
• Value types directly contain their data, and instances of value types are either allocated on the stack or allocated inline in a structure. Value types can be built-in (implemented by the runtime), user-defined, or enumerations.

Reference types:        

         Reference types store a reference to the value's memory address, and are allocated on the heap. Reference types can be self-describing types, pointer types, or interface types. The type of a reference type can be determined from values of self-describing types. Self-describing types are further split into arrays and class types. 

       The class types are user-defined classes, boxed value types, and delegates.

Boxing:

       Converting value types to reference types is also known as boxing. As can be seen in the example below, it is not necessary to tell the compiler an Int32 is boxed to an object, because it takes care of this itself.

Example:

   Int32 x = 10;

   Object o = x; // Implicit boxing

   Console.WriteLine ("The Object o = {0}",o); // prints out "The Object o =        10"

Unboxing:

      The following example intends to show how to unbox a reference type back to a value type. First an Int32 is boxed to an object, and then it is unboxed again. Note that unboxing requires explicit cast.

    Int32 x = 5;

    Object o1 = x; // Implicit Boxing

    x = (int) o1; // Explicit Unboxing

Common Language Infrastructure

     The Common Language Infrastructure (CLI) is an open specification developed by Microsoft and standardized by ISO] and ECMA that describes the executable code and runtime environment that form the core of the Microsoft .NET Framework and the free and open source implementations Mono and Portable.NET. The specification defines an environment that allows multiple high-level languages to be used on different computer platforms without being rewritten for specific architectures.

Among other things, the CLI specification describes the following four aspects:

The Common Type System (CTS) 

     A set of data types and operations that are shared by all CTS-compliant programming languages.

    Metadata Information about program structure is language-agnostic, so that it can be referenced one's not using.

Common Language Specification (CLS) 

   A set of base rules to which any language targeting the CLI should conform in order to interoperate between languages and tools, making it easy to work with code written in a language with other CLS-compliant languages. The CLS rules define a subset of the Common Type System.

Virtual Execution System (VES) 

   The VES loads and executes CLI-compatible programs, using the metadata to combine separately generated pieces of code at runtime.

    All compatible languages compile to Common Intermediate Language (CIL), which is an intermediate language that is abstracted from the platform hardware. When the code is executed, the platform-specific VES will compile the CIL to the machine language according to the specific hardware and operating system.

Functions of the Common Type System 

• To establish a framework that helps enable cross-language integration, type safety, and high performance code execution.
• To provide an object-oriented model that supports the complete implementation of many programming languages.
• To define rules that languages must follow, which helps ensure that objects written in different languages can interact with each other.
• The CTS also defines the rules that ensures that the data types of objects written in various languages are able to interact with each other.
• The CTS also specifies the rules for type visibility and access to the members of a type, i.e. the CTS establishes the rules by which assemblies form scope for a type, and the Common Language Runtime enforces the visibility rules.
• The CTS defines the rules governing type inheritance, virtual methods and object lifetime.   Languages supported by .NET can implement all or some common data types…

When rounding fractional values, the halfway-to-even ("banker's") method is used by default, throughout the Framework. Since version 2, "Symmetric Arithmetic Rounding" (round halves away from zero) is also available by programmer's option.

     it is used to communicate with other languages

 Base Class Library:

       The Base Class Library (BCL) is a Common Language Infrastructure (CLI) standard library available to all CLI languages. CLI includes the BCL in order to encapsulate a large number of common functions, such as file reading and writing, graphic rendering, database interaction, and XML document manipulation, which makes the programmer's job easier. 

      It is much larger in scope than standard libraries for most other languages, including C++, and is comparable in scope and coverage to the standard libraries of Java.

      The .NET Framework, being the first implementation of CLI, is the origin of the BCL. It is sometimes incorrectly referred to as the Framework Class Library (FCL), but the FCL is actually a superset including Microsoft specific namespaces.

      The BCL is updated with each version of the .NET Framework.

Framework Class Library:

       The Framework Class Library (FCL) is a standard library and one of two core components of Microsoft .NET Framework. The FCL is a collection of reusable classes, interfaces and value types. The Base Class Library is a part of FCL and provides the most fundamental functionality, which includes classes in namespaces System, System.CodeDom, System. Collections, System. Diagnostics, System. Globalization, System.IO, System. Resources and System.Text.

Common Language Runtime

      The .NET Framework provides a run-time environment called the common language runtime, which runs the code and provides services that make the development process easier.

Code that you develop with a language compiler that targets the runtime is called managed code; it benefits from features such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services.

      The runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used. Objects whose lifetimes are managed in this way are called managed data. Garbage collection eliminates memory leaks as well as some other common programming errors. If your code is managed, you can use managed data, unmanaged data, or both managed and unmanaged data in your .NET Framework application. Because language compilers supply their own types, such as primitive types, you might not always know (or need to know) whether your data is being managed.

      The common language runtime makes it easy to design components and applications whose objects interact across languages. Objects written in different languages can communicate with each other, and their behaviours can be tightly integrated

       For an instance, you can define a class and then use a different language to derive a class from your original class or call a method on the original class. You can also pass an instance of a class to a method of a class written in a different language. This cross-language integration is possible because language compilers and tools that target the runtime use a common type system defined by the runtime, and they follow the runtime's rules for defining new types, as well as for creating, using, persisting, and binding to types.

CLR Provide following features:

• Performance improvements.
• The ability to easily use components developed in other languages.
• Extensible types provided by a class library.
• Language features such as inheritance, interfaces, and overloading for object-oriented programming.
• Support for explicit free threading that allows creation of multithreaded, scalable applications.
• Support for structured exception handling.
• Support for custom attributes.
• Garbage collection.
• Use of delegates instead of function pointers for increased type safety and security. For more information about delegates

.Net Framework

          

           C# programs run on the .NET Framework, an integral component of Windows that includes a virtual execution system called the Common Language runtime (CLR) and a unified set of class libraries. The CLR is the commercial implementation by Microsoft of the Common Language Infrastructure (CLI), an international standard that is the basis for creating execution and development environments in which languages and libraries work together seamlessly.

            Source code written in C# is compiled into an intermediate language (IL) that conforms to the CLI specification. The IL code and resources, such as bitmaps and strings, are stored on disk in an executable file called an assembly, typically with an extension of .exe or .dll. An assembly contains a manifest that provides information about the assembly's types, version, culture, and security requirements.

             When the C# program is executed, the assembly is loaded into the CLR, which might take various actions based on the information in the manifest. Then, if the security requirements are met, the CLR performs Just in time (JIT) compilation to convert the IL code to native machine instructions. The CLR also provides other services related to automatic garbage collection, exception handling, and resource management.

             Code that is executed by the CLR is sometimes referred to as "managed code," in contrast to "unmanaged code" which is compiled into native machine language that targets a specific system. The following diagram illustrates the compile-time and run-time relationships of C# source code files, the .NET Framework class libraries, assemblies, and the CLR.

                   In addition to the run time services, the .NET Framework also includes an extensive library of over 4000 classes organized into namespaces that provide a wide variety of useful functionality for everything from file input and output to string manipulation to XML parsing, to Windows Forms controls.

  

Three Tier and N-tier Architecture - Architectures

       Three-tier (layer) is a client-server architecture in which the user interface, business process (business rules) and data storage and data access are developed and maintained as independent modules or most often on separate platforms. Basically, there are 3 layers, tier 1 (presentation tier, GUI tier), tier 2 (business objects, business logic tier) and tier 3 (data access tier). These tiers can be developed and tested separately.

       Separation of the user interface from business logic and database access has many advantages. Some of the advantages are as follows:

• Reusability of the business logic component results in quick development. Let's say we have a module that handles adding, updating, deleting and finding customers in the system. As this component is developed and tested, we can use it in any other project that might involve maintaining customers.
• Transformation of the system is easy. Since the business logic is separate from the data access layer, changing the data access layer won’t affect the business logic module much. Let's say if we are moving from SQL Server data storage to Oracle there shouldn’t be any changes required in the business layer component and in the GUI component.
• Change management of the system is easy. Let's say if there is a minor change in the business logic, we don’t have to install the entire system in individual user’s PCs. E.g. if GST (TAX) is changed from 10% to 15% we only need to update the business logic component without affecting the users and without any downtime.
• Having separate functionality servers allows for parallel development of individual tiers by application specialists.
• Provides more flexible resource allocation. Can reduce the network traffic by having the functionality servers strip data to the precise structure needed before sending it to the clients.

As more users access the system a three-tier solution is more scalable than the other solutions because you can add as many middle tiers (running on each own server) as needed to ensure good performance (N-tier or multiple-tier).

Security is also the best in the three-tier architecture because the middle layer protects the database tier.There is one major drawback to the N-tier architecture and that is that the additional tiers increase the complexity and cost of the installation.