Dotnetfreaks' Blog | Dotnetfreaks' Blog

Dotnetfreaks' Blog

Fabulous Adventures In DotNet

About the author

Author Name is someone.
E-mail me Send mail

Recent posts

Recent comments

Archive

Tags

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2014

Memory in .NET - (Vagueness Of .NET Memory Management)


Couple of days ago i met with a .net guru and we had discussion on advanced concept of .NET and Memory management; I am sharing the findings of that discussion with you. I feel that many .NET programmers still do not realize the difference between Primitive, Reference and Value types, and how they stored in memory (what goes where) and misuse of any type can lead to subtle bugs that are very hard to find. So it is very important to understand the different types that .NET Framework supports. In this article, I am going to talk about these different types briefly. 
 
"Variables" are simply storage locations for data becuase it is really hard to pragramme against the memory address. It means, a variable is just an association between a name and memory slot. You can place data into them and retrieve their contents as part of a C# expression. The size of that slot, and the interpretation of the value is controlled through "Types" - and this is where the difference between value types and reference types comes in.

Primitive types

 Any data types directly supported by the compiler are called primitive types. Primitive types map directly to types that exist in the base class library. For example, in C# an int maps directly to the System.Int32 type. Because of this, the following two lines of code are identical to the two lines of code shown previously:

System.Int32 a = new System.Int32(5);
System.Int32 a = 5; 
Above lines are identical to following lines:
 
int a = new int(5);
int a = 5;

Value Types

 A data type is a value type if it holds the data within its own memory allocation. Value types derive from System.ValueType, which derives from System.Object. Types that derive from System.ValueType have special behavior in the CLR. Value type variables directly contain their values, which means that the memory is allocated inline in whatever context the variable is declared. There is no separate heap allocation or garbage collection overhead for value-type variables. Value types include the following:
  • All numeric data types
  • Boolean, Char, and Date
  • All structures, even if their members are reference types
  • Enumerations, since their underlying type is always SByte, Short, Integer, Long, Byte, UShort, UInteger, or ULong
Every structure is a value type, even if it contains reference type members. For this reason, value types such as Char and Integer are implemented by .NET Framework structures.
You can declare a value type by using the reserved keyword, for example, Decimal. You can also use the New keyword to initialize a value type. This is especially useful if the type has a constructor that takes parameters. An example of this is the Decimal(Int32, Int32, Int32, Boolean, Byte) constructor, which builds a new Decimal value from the supplied parts.
public struct TestStruct
{
    public int x, y;

    public TestStruct(int p1, int p2)
    {
        x = p1;
        y = p2;
    }
}
Value types are sealed, which means, for example, that you cannot derive a type from System.Int32, and you cannot define a struct to inherit from any user-defined class or struct because a struct can only inherit from System.ValueType. However, a struct can implement one or more interfaces. You can cast a struct type to an interface type; this causes a boxing operation to wrap the struct inside a reference type object on the managed heap. Boxing operations occur when you pass a value type to a method that takes a System.Object as an input parameter. 

Reference Types

A reference type contains a pointer to another memory location that holds the data. Reference types include the following:
  • String
  • All arrays, even if their elements are value types
  • Class types, such as Form
  • Delegates
A class is a reference type. For this reason, reference types such as Object and String are supported by .NET Framework classes.
 
Note that every array is a reference type, even if its members are value types.
 
Since every reference type represents an underlying .NET Framework class, you must use the New Operator (Visual Basic) keyword when you initialize it. The following statement initializes an array. The value of a reference type variable is always either a reference or null. If it's a reference, it must be a reference to an object which is compatible with the type of the variable. The slot of memory associated with the variable is just the size of a reference, however big the actual object it refers to might be. (On the 32-bit version of .NET, for instance, a reference type variable's slot is always just 4 bytes.)

Elements That Are Not Types

The following programming elements do not qualify as types, because you cannot specify any of them as a data type for a declared element:
  • Namespaces
  • Modules
  • Events
  • Properties and procedures
  • Variables, constants, and fields  

So where are things stored?

The memory slot for a variable is stored on either the stack or the heap. It depends on the context in which it is declared:
  • Each local variable (ie one declared in a method) is stored on the stack. That includes reference type variables - the variable itself is on the stack, but remember that the value of a reference type variable is only a reference (or null), not the object itself. Method parameters count as local variables too, but if they are declared with the ref modifier, they don't get their own slot, but share a slot with the variable used in the calling code.
  • Instance variables for a reference type are always on the heap. That's where the object itself "lives".
  • Instance variables for a value type are stored in the same context as the variable that declares the value type. The memory slot for the instance effectively contains the slots for each field within the instance. That means (given the previous two points) that a struct variable declared within a method will always be on the stack, whereas a struct variable which is an instance field of a class will be on the heap.
  • Every static variable is stored on the heap, regardless of whether it's declared within a reference type or a value type. There is only one slot in total no matter how many instances are created. (There don't need to be any instances created for that one slot to exist though.)
There are a couple of exceptions to the above rules - captured variables (used in anonymous methods and lambda expressions) are local in terms of the C# code, but end up being compiled into instance variables in a type associated with the delegate created by the anonymous method. The same goes for local variables in an iterator block.



Happy reading...........
 



Posted by Ajander Singh on Tuesday, November 29, 2011 3:09 PM
Permalink | Comments (2) | Post RSSRSS comment feed

Ajax Client Life-Cycle Events


A WebForms based page that uses Microsoft Ajax raises the same server life-cycle events as an ASP.NET 4 Web page and in addition raises client life-cycle events. The client events enable you to customize the UI for both postbacks and for asynchronous postbacks (partial-page updates). The client events also help you manage custom script components during the lifetime of the page in the browser.

The client events are raised by classes in the Microsoft Ajax Library. These classes are automatically instantiated when a page contains Microsoft Ajax server controls. The client classes provide APIs that enable you to bind to events and to provide handlers for those events. Because the Microsoft Ajax Library is browser independent, the code you write for your handlers works the same in all supported browsers.

The key event for initial requests (GET requests) and synchronous postbacks is the load event of the Application instance. When script in a load event handler runs, all scripts and components have been loaded and are available. When partial-page rendering with UpdatePanel controls is enabled, the key client events are the events of the PageRequestManager class. These events enable you to handle many common scenarios. These include the ability to cancel postbacks, to give precedence to one postback over another, and to animate UpdatePanel controls when their content is refreshed.

Client events are useful whether you are creating pages or writing components. If you are a page developer, you can provide custom script that is called when the page loads and unloads in the browser.

For more information about the server life-cycle events, see ASP.NET Page Life Cycle Overview.

Client Classes


The two main Microsoft Ajax Library classes that raise events during the client life cycle of a WebForms based page are the Application and PageRequestManager classes.

The Application class is instantiated in the browser when the page contains a ScriptManager control. The Application class resembles the Page server control, which derives from the Control class, but provides additional functionality for raising server events. Similarly, the Application class derives from the Sys.Component class, but raises client life-cycle events that you can handle.

If a page contains a ScriptManager control and one or more UpdatePanel controls, the page can perform partial-page updates (if partial-page rendering is enabled and supported in the browser). In that case, an instance of the PageRequestManager class is automatically available in the browser. The PageRequestManager class raises client events that are specific to asynchronous postbacks. For details about partial-page rendering, see Partial-Page Rendering Overview.

Adding Handlers for Client Events


To add or remove handlers for events raised by the Application and PageRequestManager classes, use the add_eventname and remove_eventname methods of those classes. The following example shows how to add a handler named MyLoad to the init event of the Application object.

JavaScript

Sys.Application.add_init(MyInit);
                function MyInit(sender) {
                }
                Sys.Appplication.remove_init(MyInit);
                

Handling the Application Load and Unload Events

To handle the load and unload events of the Application object, you do not have to explicitly bind a handler to the event. Instead, you can create functions that use the reserved names pageLoad and pageUnload. The following example shows how to add a handler for the load event of the Application object by using this approach.

JavaScript

function pageLoad(sender, args) {
                }
            

Events for Other Client Classes

This topic describes only the events that are raised by the Application and PageRequestManager classes. The Microsoft Ajax Library also contains classes for adding, clearing, and removing handlers for DOM element events. These classes include the following:

Events raised by DOM elements are not discussed in this topic.

Client Events of the Application and PageRequestManager Classes


The following table lists client events of the Application and PageRequestManager classes that you can handle in Ajax enabled ASP.NET Web pages. The order in which the events are raised is described later in this topic.

Event

Description

Sys.Application.init Event

Raised after all scripts have been loaded but before any objects are created. If you are writing a component, the init event gives you a point in the life cycle to add your component to the page. The component can then be used by other components or by script later in the page life cycle. If you are a page developer, you should use the load event instead of the init event for most scenarios.

The init event is raised only one time when the page is first rendered. Subsequent partial-page updates do not raise the init event.

Sys.Application.load Event

Raised after all scripts have been loaded and all objects in the application that are created by using $create are initialized. The load event is raised for all postbacks to the server, which includes asynchronous postbacks.

If you are a page developer, you can create a function that has the name pageLoad, which automatically provides a handler for the load event. The pageLoad handler is called after any handlers that have been added to the load event by the add_load method.

The load event takes an eventargs parameter, which is an Sys.ApplicationLoadEventArgs object. You can use the event arguments to determine whether the page is being refreshed as a result of a partial-page update and what components were created since the previous load event was raised.

Sys.Application.unload Event

Raised before all objects are disposed and before the browser window's window.unload event occurs.

If you are a page developer, you can create a function that has the name pageUnload, which automatically provides a handler for the unload event. The pageUnload event is called just before the page is unloaded from the browser. During this event, you should free any resources that your code is holding.

Sys.Component.propertyChanged Event

Potentially raised when a property of a component changes. This event is raised only if a component developer has called the Sys.Component.raisePropertyChange method in a property set accessor. For more information, see Defining Custom Component Properties and Raising PropertyChanged Events.

The propertyChanged event takes an eventargs parameter, which is a Sys.applicationLoadEventArgs object.

Sys.Component.disposing Event

Raised when the Application instance is disposed.

Sys.WebForms.PageRequestManager initializeRequest Event

Raised before an asynchronous request starts. You can use this event to cancel a postback, such as to give precedence to another asynchronous postback.

The initializeRequest event takes an eventargs parameter, which is a Sys.WebForms.InitializeRequestEventArgs object. This object makes available the element that caused the postback and the underlying request object. InitializeRequestEventArgs also exposes a cancel property. If you set cancel to true, the new postback is canceled.

Sys.WebForms.PageRequestManager beginRequest Event

Raised before an asynchronous postback starts and the postback is sent to the server. If there is a postback already processing, it is stopped (by using the abortPostBack method). You can use this event to set request headers or to begin an animation on the page to indicate that the request is in process.

The beginRequest event takes an eventargs parameter, which is a Sys.WebForms.BeginRequestEventArgs object. This object makes available the element that caused the postback and the underlying request object.

Sys.WebForms.PageRequestManager pageLoading Event

Raised after the response from the server to an asynchronous postback is received, but before any content on the page is updated. You can use this event to provide a custom transition effect for updated content.

The pageLoading event takes an eventargs parameter, which is an Sys.WebForms.PageLoadingEventArgs object. This object makes available information about what panels will be deleted and updated as a result of the most recent asynchronous postback.

Sys.WebForms.PageRequestManager pageLoaded Event

Raised after all content on the page is refreshed, as a result of either a synchronous or an asynchronous postback. For synchronous postbacks, panels can only be created, but for asynchronous postbacks, panels can be both created and updated. You can use this event to manage a custom transition effect for updated content.

The pageLoaded event takes an eventargs parameter, which is an Sys.WebForms.PageLoadedEventArgs object. This object makes available information about which panels were updated and created in the most recent postback.

Sys.WebForms.PageRequestManager endRequest Event

Raised after the response for an asynchronous postback is processed and the page is updated, or during the processing of the response if there is an error. If an error occurs, the page is not updated. Use this event to provide customized error notification to users or to log errors.

The endRequest event takes an eventargs parameter, which is a Sys.WebForms.EndRequestEventArgs object. This object makes available information about errors that have occurred and whether the error was handled. It also makes available the response object.

Event Order for Common Scenarios


The order of events depends on what controls are used on the page and what type of request is made (initial request, postback, or asynchronous postback). This section describes the order of events for several common scenarios.

Initial Request

During the initial request for the page, a limited number of client events are raised. Assume the following scenario for the initial request:

The following client events occur, in this order:

  1. The initial request is sent to the server.

  2. The response is received by the client.

  3. The Application instance raises the init event.

  4. The Application instance raises the load event.

The init event of the Application instance is raised only one time for the life of the page in the browser. It is not raised for subsequent asynchronous postbacks. During an initial request, no PageRequestManager events are raised.

Asynchronous Postback

An asynchronous postback sends some page data to the server, receives a response, and updates a part of the page. Assume the following scenario for an asynchronous postback:

The following client events occur, in this order:

  1. The button inside the UpdatePanel is clicked, which initiates an asynchronous postback.

  2. The PageRequestManager instance raises the initializeRequest event.

  3. The PageRequestManager instance raises the beginRequest event.

  4. The request is sent to the server.

  5. The response is received by the client.

  6. The PageRequestManager instance raises the pageLoading event.

  7. The PageRequestManager instance raises the pageLoaded event.

  8. The Application instance raises the load event.

  9. The PageRequestManager instance raises the endRequest event.

For more information, see Working with Partial-Page Rendering Events.

Note that the load event of the Application instance is raised after the PageRequestManager pageLoaded event and before its endRequest event.

Multiple Asynchronous Postbacks

Multiple asynchronous postbacks can occur when users initiate a new request before a previously initiated request has finished processing on the server or in the browser. Assume the following scenario for multiple asynchronous postbacks:

  • The page contains a ScriptManager control and the control's SupportsPartialRendering and EnablePartialRendering property are both true.

  • The page contains an UpdatePanel control.

  • A button inside the UpdatePanel control that initiates an asynchronous postback is clicked two times. The second click occurs while the server is processing the request initiated by the first click.

  • A response to the first request is returned successfully from the server.

The following client events occur, in this order:

  1. A button inside the UpdatePanel is clicked, which initiates an asynchronous postback.

  2. The PageRequestManager instance raises the initializeRequest event.

  3. The PageRequestManager instance raises the beginRequest event.

  4. The request is sent to the server.

  5. The button is clicked again, which initiates a second asynchronous postback.

  6. The PageRequestManager instance raises the initializeRequest event for the second button click.

  7. The PageRequestManager instance raises the endRequest event for the first button click.

  8. The PageRequestManager instance raises the beginRequest event for the second button click.

  9. The request initiated by the second click is sent to the server.

  10. The response is received for the second click.

  11. The PageRequestManager instance raises the pageLoading event.

  12. The PageRequestManager instance raises the pageLoaded event.

  13. The Application instance raises the load event.

  14. The PageRequestManager instance raises the endRequest event.

The default behavior of asynchronous postbacks is that the most recent asynchronous postback takes precedence. If two asynchronous postbacks occur in sequence, and if the first postback is still being processed in the browser, the first postback is canceled. If the first postback has been sent to the server, the server processes the second request when it arrives and does not return the first request. For information about how to give precedence to a specific asynchronous postback, see Giving Precedence to a Specific Asynchronous Postback.

Browsing Away from a Page

When the user browses away from a page, the current page is unloaded from the browser and you can handle the unload event to free resources. Assume the following scenario for browsing away from a page:

The following client events are raised, in this order:

  1. The request for new page is initiated.

  2. The response for the new page is received by the browser.

  3. The Application instance raises the unload event.

  4. The new page is displayed.

If there is an error in the request for the new page, the unload event is still raised, but the new page is not displayed.

MSAJaxEvents.pdf (101.83 kb)




Posted by Ajander Singh on Wednesday, June 29, 2011 6:43 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Diffrence between HLD and LLD


What is HLD?

High Level Design gives the overall System Design in terms of Functional Architecture and Database design. It is very important document of any software and very useful for the developers to understand the flow of the system. It gives the complete overview of the system and tells to everyone how the system is going to divided into sub systems (functions, modules). In this phase design team, review team (testers) and customers plays a major role. For this the entry criteria are the requirement document that is SRS. And the exit criteria will be HLD, projects standards, the functional design documents, and the database design document. Further, High level deign gives the overview of the development of product. In other words how the program is going to be divided into functions, modules, subdivision etc.


What is LLD?

Low Level Design (LLD): During the detailed phase, the view of the application developed during the high level design is broken down into modules and programs. Logic design is done for every program and then documented as program specifications. For every program, a unit test plan is created. The entry criteria for this will be the HLD document. And the exit criteria will the program specification and unit test plan (LLD).
The Low Level Design Document gives the design of the actual program code which is designed based on the High Level Design Document. It defines Internal logic of corresponding submodule designers are preparing and mapping individual LLD's to Every module. A good Low Level Design Document developed will make the program very easy to be developed by developers because if proper analysis is made and the Low Level Design Document is prepared then the code can be developed by developers directly from Low Level Design Document with minimal effort of debugging and testing.




Posted by Ajander Singh on Wednesday, June 29, 2011 6:01 PM
Permalink | Comments (0) | Post RSSRSS comment feed