When to Use What:
—————————-
Areas where SOAP based WebServices is a great solution:
If application needs a guaranteed level of reliability and security
If both sides (provider and consumer) have to agree on the exchange format
If the application needs state management

Areas where RESTful WebServices are a great choice:
Return structure is really in any format (developer defined).
Any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs.
REST can also use the XMLHttpRequest object – AJAX support
If you need stateless operations like CRUD (Create, Read, Update, and Delete) then REST is suitable.
If the application information needs to be cached.

Differences:
—————–
REST defines a transport-Specific (HTTP) model, focused on RESOURCES
sOAP defines a transport-Neutral (HTTP/TCP/SMTP/MSMQ) model, focused on CUSTOM OPERATIONS

REST emphasizes NOUNs (with REST, you define resources and use a Uniform Interface to operate on them using GET/PUT/DELETE/POST)
SOAP emphasizes VERBs (with SOAP, you define operations which tunnels through POST)

REST => Employee{}
EmpAddress{}
SOAP => getEmployee(), addEmployee(), RemoveEmployee(),
getEmpAddress(),addEmpAddress(),…

REST is used in highly-scalable Web-centric scenarios
SOAP is used in Enterprise scenarios (where you need COM+ like capabilities)
REST is focused on accessing named resources //getUser(User);
SOAP is focused on accessing named operations //switchCategory(User, OldCategory, NewCategory)

REST exposes data as services
SOAP exposes application logic as services and not data

REST permits many different data formats. JSON is used to handle different data formats.
SOAP only permits XML

REST doesn’t deal will standard messaging system and expects the clients to deal with it
SOAP provides end-to-end reliability using WS-ReliableMessaging.

REST uses only HTTP/HTTPS protocol
SOAP uses multiple protocol – SMTP (Simple Mail Transfer Protocol) and even JMS (Java Messaging Service).

REST is limited by HTTP, it can’t provide two-phase commit across distributed transactional resources.
General Internet apps don’t need this level of transactional reliability
SOAP supports WS-AtomicTransaction, thats ACID compliant. Enterprise level/ Financial apps needs SOAP.

REST provides transactions, but they aren’t ACID compliant
SOAP provides ACID compliant transactions

REST reads can be cached
SOAP reads cannot be cached.

REST supports SSL(point to point) security
SOAP supports WS-Security providing enterprise security features

Note:
——–
REST can do just about anything SOAP can, but without established standards.

Yahoo, Amazon and Ebay uses REST for their services.

Google used only SOAP but in 2006 they deprecated to REST.

Thanks to Mike Rozlog & Steve Francia for there presentations.

In MVC comes with two models
1.Passive model
2.Active model

Passive model: Used when one controller manipulates the model exclusively. The controller modifies the model and then informs the view that the model has changed and should be refreshed (see Figure 2). The model in this scenario is completely independent of the view and the controller, which means that there is no means for the model to report changes in its state
The HTTP protocol is an example of this. The browser displays the view and responds to user input, but it does not detect changes in the data on the server. Only when the user explicitly requests a refresh is the server interrogated for changes

Active model: Used when the model changes state without the controller’s involvement. This can happen when other sources are changing the data and the changes must be reflected in the views. Consider a stock-ticker display. You receive stock data from an external source and want to update the views when the stock data changes. Because only the model detects changes to its internal state when they occur, the model must notify the views to refresh the display.

If the model had to notify the views of changes, you would reintroduce the dependency you were looking to avoid. Fortunately, the Observer pattern provides a mechanism to alert other objects of state changes without introducing dependencies on them

The individual views implement the Observer interface and register with the model. The model tracks the list of all observers that subscribe to changes. When a model changes, the model iterates through all registered observers and notifies them of the change. This approach is often called “publish-subscribe.” The model never requires specific information about any views.

Architecting the presentation layer around the MVC pattern results in the following advantages: Supports multiple views and Accommodates GUI change

Disadvantages: •
Since its event-driven nature of the user-interface code, which can become more difficult to debug.
Developers of the model can ignore the nature of the views. If the model undergoes frequent changes, it could flood the views with update requests. Therefore, it is important to keep the view in mind when coding the model.
Observer. Is a pattern that is often mentioned in conjunction with MVC due to the need to keep the views and the associated model synchronized.

Page Controller and Front Controller describe implementation strategies for the controller portion of the MVC pattern.

Page Controller
How do you best structure the controller for Simple Web applications so that you can achieve reuse and flexibility while avoiding code duplication?

Use the Page Controller pattern to accept input from the page request, invoke the requested actions on the model, and determine the correct view to use for the resulting page. The view in turn depends on the model for retrieval of data to be displayed

Defining a separate page controller isolates the model from the specifics of the Web request. Creating a separate controller for each Web page (or action) can lead to significant code duplication. Therefore, you should create a BaseController class to incorporate common functions such as validating parameters.

Disadvantages: One controller per page, Deep inheritance trees, code duplication

Front Controller
How do you best structure the controller for Very Complex Web applications so that you can achieve reuse and flexibility while avoiding code duplication?

Front Controller solves the decentralization problem present in Page Controller by channeling all requests through a single controller. The controller itself is usually implemented in two parts: a handler and a hierarchy of commands

Due to these factors the UI gets bloated with cluttered code.
Code maintenance too becomes a big headache.

Presentation logic should not decide what to show to the user. So let’s split this into two layers.
The Presentation layer should receive user input and display output.
The Application layer should make calls to the model and decide what to show to the user

General Terms (Optional):
Data lies in the database is called “RecordState”.
Data lies within the application (in-memory) is called “Session Set”.
Data lies within the GUI Controls are called “ScreenState”.
To keepScreenStateandSessionStatesynchronized we use Data Binding concept.
Data Binding handles much of the functionality of a client-server application.
Forms are responsible for Screen Layout and Form Logic.
Form observes the controls its holds.
Form has handler methods to react to events raised by the controls we are interested with.
Simple data changes are handled through data binding, whereas complex changes are handled using form’s event handling methods.

MVC.
The main purpose of the controller class is to map the action to the view after loading the model. (Whereas when loading home page no model object is required)
So the controller role is to load the model and call the view.
Controller uses ViewData to make the model available to view.
In MVC, it is not allowed to access the view directly, therefore the model (business object) changes are propagated to view through the observer mechanism. (using presentation model).
Therefore in order to make the view update itself, the controller should change the presentation model object (not the actual business model objects). Controller cannot simply send a message to the view.
To implement this, make the model OBSERVABLE and make the view OBSERVER. Thus whenever the business objects (model) changes it notifies the views automatically.
Each OBSERVER is registered with OBSERVABLE.
In general controller calls write methods on model objects and similarly view calls read methods on model objects to update the view.
In this scenario, each write method in observable (model) calls a notification method in each observer (view).Notification method in observer reads model
(Observers may have multiple observerables with common notification method. Notification method parameter indicates which observable.)

Application Flow: When user makes an update on the screen, the user inputs are passed to the controller, which in turn calls Write method on model object. Now the model object in turn calls the notification method on the view which in turn calls the read method on model object. Thus the view gets updated automatically when model changes.

View only renders the presentation model and presents them to the user. In MVC, view does not contain any complex or application logic.

In MVC, the View doesn’t speak to Controller or Model directly. Everything happens here through Presentation Model classes.

The Data Binding between Controller and View takes place using “ViewData” Concept

View access the model using ViewData object
[Controller]  —> [ViewData] —-> [View]
—————–Model—————–>

Drawbacks of MVC:
1.  Higher implementation complexity involved because of observer mechanism. Harder to understand and maintain code (due to indirect linking of controller to view through presentation object)
2.  Direct requests from the controller to view is not possible
3.  MVC does not conform to modern UI programming environments. Ex. Form classes in .NET application by default contains handlers for user inputs.
     It would be difficult to break that default pattern and make controllers to receive the user input instead of views.
4.While implementing we need to introduce a new class called Presentation model.

Advantages:
1. MVC provides a clear distribution of responsibilities between parties. Keep application logic and UI code in separate classes.
2. Since view in MVC does not contain any application logic, controller can load the model in different views with easy.
3. One model can have multiple views and controller pairs.

When to use MVC:
1. If the application is more report oriented where diferent reports can be shown using same ASPX page but with different models.
    So if your application has same UI with some slight variation MVC is a good fit.
Mapping is done at RegisterRoutes() method. {Default/controller/action/id == http://localhost/Employee/ViewEmployeeSalesReport/001}

Simple Example for using ViewData concept( lets forget about Presentation model class here):
public class EmployeeModel
{
     private int      _empid;
     private string _strempname;
     private string _customername;
     private double _salesprofit;
     public int EmpId{get; set;}
    public string EmpName{get; set;}
    public string CustomerName{get; set;}
    public double SalesProfit{get; set’;}

    public void LoadCustomer(int empid)
   {
      //loads employee data from database based on empid
   }
};

public class EmployeeController : Controller
{
    public ActionResult ViewEmployeeSalesReport(string id)
     {
         EmployeeModel  objEmpModel = new EmployeeModel();
         objEmpModel.LoadEmployeeDetails(id);
          ViewData["Employee"] = objempModel;
          return View();
      }    
}

public partial class ViewEmployeeSalesReport: ViewPage
{
    protected void Page_Load(object sender, EventArgs e)
   {
      datagrid1.DataSource = (EmployeeModel) ViewData["Employee"];
      datagrid1.DataBind();
   }
}

MVP.
 If your goal is to
1. decouple model from view &
2. reuse presentation logic irrespective of the UI type (windows / web
Then you have to choose MVP.
MVP basically centralizes the presentation logic. Move this presentation logic to a separate class called PRESENTER.
This also makes the UI testing simple. 
In MVP, the Controller makes direct calls to the View. (calling through Interface -IView)
This allows developer to easily support interchangeable views for Web and Windows environments.
In this model presenter can talk to view. (whereas in MVC, the controller cannot talk to view)
In MVP, the Presenter always talks to the View through an interface. In this way the model is never in touch with the UI (aspx / windows interface). All user interface should implement this View interface so that the presenter can communicate with the UI in a decoupled manner.

The INotifyPropertyChanged interface is the key for data binding. If the data changes in the view models need to be reflected in the XAML components through bindings, all the view models in a Silverlight MVVM application need to implement this interface

In MVP views receive user input and then delegates processing to the corresponding controllers. That is why MVP pattern better fits modern UI environments (Windows/Web forms) where view classes themselves handle user inputs.

With the release of Silverlight 4, the Managed Extensibility Framework (MEF) became a first class citizen of the .NET Framework 4.0. MVVM  has quickly become the most popular pattern for developing Silverlight applications. The Managed Extensibility Framework (MEF) simplifies the creation of extensible applications. MEF can assist you with building dynamic, modular, extensible, testable applications faster than ever before

Here
All user actions are passed to the Presenter,
the UI is decoupled from the model.
the Presenter is not tied up with the business objects

Implement StockBO, IStockView and Presenter as Class Library (dll) in C#
namespace StockBO
{
public class Stock
{
public static int intStockValue;

public static void IncrementStock()
{
intStockValue++;
}
public static void DecrementStock()
{
intStockValue–;
}
public static int getStatus()
{
if (intStockValue > 5)
return 1;
else if (intStockValue < 0)
return -1;
else
return 0;
}
}
}

namespace IStockView
{
public interface StockView
{
void setStockValue(int intStockValue);
void setColor(System.Drawing.Color objColor);
}
}

using IStockView;
using StockBO; //Stock
namespace Presenter
{
public class clsPresenter
{
StockView iObjStockView;

public void add(StockView ObjStockView)
{
iObjStockView = ObjStockView;
}

public void increaseStock()
{
Stock.IncrementStock();
iObjStockView.setStockValue(Stock.intStockValue);
ChangeColor();
}

public void decreaseStock()
{
Stock.DecrementStock();
iObjStockView.setStockValue(Stock.intStockValue);
ChangeColor();
}

public void ChangeColor()
{
if(Stock.getStatus()==-1)
iObjStockView.setColor(Color.Red);
else if (Stock.getStatus() == 1)
iObjStockView.setColor(Color.Blue);
else
iObjStockView.setColor(Color.Green);
}
}
}

//Add reference dlls (IStockView.dll, Presenter.dll)
using IStockView;
using Presenter;
namespace WindowsMVPStock
{
public partial class Form1 : Form,StockView
{
clsPresenter objpresenter = new clsPresenter();

//Form Members
private void Form1_Load(object sender, EventArgs e)
{
objpresenter.add(this);
}

private void btnInCreaseStock_Click(object sender, EventArgs e)
{
objpresenter.increaseStock();
}

private void btnDecreaseStock_Click(object sender, EventArgs e)
{
objpresenter.decreaseStock();
}

//StockView Members
public void setStockValue(int intStockValue)
{
txtStockValue.Text = intStockValue.ToString();
}

public void setColor(Color objColor)
{
txtStockValue.BackColor = objColor;
}
}
}

//Add reference dlls (IStockView.dll, Presenter.dll, StockBO.dll)
using IStockView;
using Presenter;
public partial class DisplayStock : System.Web.UI.Page,StockView
{
private clsPresenter objPresenter = new clsPresenter();

//Form Members
protected void Page_Load(object sender, EventArgs e)
{
objPresenter.add(this);
}
protected void btnIncreaseStock_Click(object sender, EventArgs e)
{
objPresenter.increaseStock();
}
protected void btnDecreaseStock_Click(object sender, EventArgs e)
{
objPresenter.decreaseStock();
}

//StockView Members
public void setStockValue(int intStockValue)
{
txtStockValue.Text = intStockValue.ToString();
}
public void setColor(System.Drawing.Color objColor)
{
txtStockValue.BackColor = objColor;
}

}

MVVM
MVVM is a specialized Design Pattern for WPF and Silverlight applications.
In a WPF MVVM application, the Models will go through the View-Model classes to communicate with the Views (UI).
This View-Model class inherits from the "ViewModelBase" class

If you want to create your own View-Models, you should also make your View-Model classes inherit from "ViewModelBase" class
The "ViewModelBase" class implements the "INotifyPropertyChanged" interface, so the UI (View) will be notified when a public property bounded to it is changed.

One thing to remember about the view is that it is not responsible for maintaining its state. Instead, it will synchronize this with the viewmodel.

In MVVM. the views are expressed as XAML

In MVVM, the View and Model plays the same role as in MVC. The only difference here is the concept of ViewModel. This is an abstract representation of user interface class exposing both properties and operations that can be invoked from UI
Unlike Contollers in MVC, Presenter in MVP, an MVVM ViewModel has no awareness that a view even exists. Instead MVVM view uses WCF/Silverlight binding features with allows you to associate bidirectionally the UI’s Control properties with the properties exposed by the ViewModel.

The whole MVVM pattern is designed around WCF/Silverlight binding’s features, so it does not always make sense to apply it on other technology platforms.

First, the IConfig represents a configuration service (in a newsreader it may contain the account information and feeds that are being fetched), while the IService is “some service” – perhaps the interface to fetch feeds from RSS sources in a news reader application.

The View and the ViewModel

The view and the viewmodel communicate via data-binding, method calls, properties, events, and messages

The viewmodel exposes not only models, but other properties (such as state information, like the “is busy” indicator) and commands

The view handles its own UI events, then maps them to the viewmodel via commands

The models and properties on the viewmodel are updated from the view via two-way databinding
Two mechanisms that often factor into implementations of the pattern are triggers (especially data triggers) in WPF, and the Visual State Manager (VSM) in Silverlight. These mechanisms help implement the pattern by binding UI behaviors to the underlying models.
In Silverlight, the VSM should be the primary choice for coordination of transitions and animations

You might have heard discussion about view first or viewmodel first. In general, I believe most developers agree that a view should have exactly one viewmodel. There is no need to attach multiple viewmodels to a single view.
A view may be composed of other views, each with its own viewmodel. Viewmodels might compose other viewmodels when necessary

Dis-Advantages
The overhead in implementing MVVM is “overkill” for simple UI operations. For larger applications, generalizing the View layer becomes more difficult. Moreover, data binding, if not managed well, can result in considerable memory consumption in an application

Advantages
One of the major claimed advantages of MVVM is that due to the separation of business data objects from the UI, we can simply change the UI without touching the business objects. It may be true in some circumstances when the changes to the UI are cosmetic changes. In practice, most of the changes to the UI due to business requirements will be functional changes. These changes will almost always require us to change the UI and the data objects together.

References and pictures borrowed from:

http://www.mvcsharp.org

Shivprasad koirala @ codeproject.com
Dr. Song Li @ codeproject.com
Jeremy likness @ csharperimage.jeremylikness.com

REST – REpresentational State Transfer
A Webpage is a representation of a resource.
Resources are just concepts.
URI’s tell a client that there is a concept somewhere
Clients can then request a specific representation from the representations the server makes available

Resources are retrieved NOT as string or blobs, but as complete representations.

Resources are identified by uniform resource indentifiers (URI’s)
URI’s are equivalent to NOUN
Verbs describe actions that are applicable to nouns
Some verbs only apply to a few nouns

REST language has trillions of nouns
In RESt we use universal verbs only
There are only 4 verbs for every noun – GET, POST, PUT, DELETE
PUT- is used to update information

Every useful data object has an address.Resources themselves are the targets for method calls. the list of methods is fixed for all resources.

Every URI could have a human-reable and a machin-processable representation
– webservices asks for machine readble one
– browser ask for human reable one

XmlHttpRequest object lets you to do REST from inside a webpage.

Advantages:
HTTP, URIs and actual data resources acquired from URIs are sufficient to describe any complex transaction including
– session state
– applicaiton state (authentication /authorization)
Enables transfer of data in streams of unlimited size and type
Scales well to large number of clients
Seperates server implementation from client perception of resources.
REST Messages are self-descriptive and stateless. Therefore message must get application state included. Application state is required by the server to understand how to process a request.

REST vs RPC
REST is a species of RPC, except the methods have been defined in advance
Most RPC applications dont adhere to REST philosophy
Assume RPC call “getStockPrice” – it is not clear what it means.
This is not a resource.Its a verb, not a Noun
But if we change the name to “CurrentStockPrice” , now its a noun. A resource. Rest is just a design style not an architecture change.

REST is incompatible with “End Point” RPC concepts
REST address data objects
RPC address software components using End-Points (SOAP began as pure RPC)

Thanks to John Cowan for his presentation.

An example of an immutable type is
DateTime =>The method AddMinutes does not modify the object – it creates and returns a new DateTime.
string => For a mutable class similar to string you can use the class StringBuilder

There is no keyword in C# to declare a type as immutable. Instead you should mark all member fields as readonly to ensure that they can only be set in the constructor. This will prevent you from accidentally modifying one of the fields, breaking the immutability.

In practice, if you want to create an immutable type, you only allow getters on it and do not allow any state changes (so any private field cannot change once the constructor finished running).

Defining an immutable object with a C# class involves discipline in not changing the private state

Dependency Injection is a design pattern to implement loosely coupled, reusable and testable object thereby allowing the architecture to link objects rather than the object linking themselves.

This design allows you to isolate the implementation of an object from the construction of objects on which it depends.
public class A ();
public class B
{
A objA = new A();
}

Why to use this design?
Loose coupling, centralized configurable and easily testable.

Types of Dependency Injection?
1. Construction Injection interface IAuto {}
public class BMW : IAuto(}
public class Honda: IAuto{}
public class Facade
{
private IAuto objAuto;
public Facade(IAuto obj)
{this.objAuto = obj;}
}
IAuto objbmw = new BMW();
Facade objFacade = new Facade(objbmw);

Drawback:
1. Once the class is instantiated you no loger change the
objects dependency.
2. Constructors dont get inherited

2. Setter Injection public class Facade
{
private IAuto autoType;
public IAuto AutoType
{
get{return autoType;}
set{autoType= value;}
}
}
IAuto objbmw = new BMW();
Facade objFacade = new Facade();
objFacade.AutoType = objbmw;

Adv :
You can change the dependency after instantiating an object .
Drawback:
Object with setters cannot be immutable

3. Interface-based Injection public class Facade
{
private IAuto autoType;
public void SetAutoType( IAuto autoType)
{
this.autoType = autoType;
}
}
IAuto objbmw = new BMW();
Facade objFacade = new Facade();
objFacade.SetAutoType(objbmw);

When ASP.NET receives the first request for any resource in an application, a class named ApplicationManager creates an application domain. Application domains provide isolation between applications for global variables and allow each application to be unloaded separately. Within an application domain, an instance of the class named HostingEnvironment is created, which provides access to information about the application such as the name of the folder where the application is stored

After the application domain has been created and the HostingEnvironment object instantiated, ASP.NET creates and initializes core objects such as HttpContext, HttpRequest, and HttpResponse

The HttpContext class contains objects that are specific to the current application request, such as the HttpRequest and HttpResponse objects. The HttpRequest object contains information about the current request, including cookies and browser information. The HttpResponse object contains the response that is sent to the client, including all rendered output and cookies.

After all core application objects have been initialized, the application is started by creating an instance of the HttpApplication class.

An instance of HttpApplication processes only one request at a time.

The first time an ASP.NET page or process is requested in an application, a new instance of HttpApplication is created. However, to maximize performance, HttpApplication instances might be reused for multiple requests. When an instance of HttpApplication is created, any configured modules are also created (SessionStateModule, FormsAuthenticationModule). After all configured modules are created, the HttpApplication class’s Init method is called.

Application Life Cycle in General
User requests an application resource from the Web server.
ASP.NET receives the first request for the application.
ASP.NET core objects are created for each request.
An HttpApplication object is assigned to the request
The request is processed by the HttpApplication pipeline.

Global.asax
To handle application events or methods, you can create a file named Global.asax in the root directory of your application. If you add modules to your application, the modules themselves can raise events. The application can subscribe to in these events in the Global.asax file by using the convention modulename_eventname

ASP.NET pages are compiled, not interpreted. Instead of reading and interpreting
your code every time a dynamic page is requested, ASP.NET compiles
dynamic pages into efficient binary files that the server can execute very
quickly. This represents a big jump in performance when compared with the ASP (interpreted predecessor)

From DLL’s point of view
1. Client browser requests for an ASP.Net page to WebServer ( a computer where IIS and .NET framework installed)
2. When IIS(inetinfo.exe) receives an HTTP request, it uses the filename extension of the requested resource to determine which ISAPI(Internet server application programming interface) program to run to process this request.
When the request is for an .aspx page it passes the request to the ISAPI DLL (aspnet_isapi.dll) capable of handling request for ASP.NET pages.
3.The aspnet_isapi.dll passes the request to ASP.Net Worker process(aspnet_wp.exe) to process the request
4.The aspnet_wp.exe compiles the .aspx file into an assembly. creates an application domain and instructs the CLR to execute the resulting assembly in the newly created application domain.
5.When the assembly for an ASP.Net page executes it uses services provided by various classes in the Framework to accomplish the given task and generates a response message for the requesting client
6.The aspnet_wp.exe collects the response generated by the execution of the webpage, creates a response packet and passes it to the aspnet_isapi.dll process
7.aspnet_isapi.dll forwards the response packet to IIS which in turn passes the response to the requestin client machine.

NOTE: Each ASP.NET page is converted to a class file (derived from System,Web.UI.Page) and is compiled into a DLL file. This class is compilee into a DLL file when the .aspx page is opened in the browser for the first time. All the HTML & C# code in the .aspx page becomes part of the class file. The HTML elements are stored in strings and do not interfere with the compilation process. The compiled dll files are managed by ASP.NET using a special directory structure within the “TemporaryASP.NET Files” directory under c:\winnt\microsoft.net\framework\v1.0.3705\TemporaryASP.net Files
ASP.NET maintains a reference between the source .aspx page and the dll file.
IMPORTANT:
Take care not to define class level code such as variable declaration, methods etc between the render blocks in an .aspx page.
Always write such things inside block.
->as a code declaration block, marks the start of serverside
code. ASP.NET know that this tag should be processed before sending the page to the browser.
ASP.NET Provides a mechanism to separate the user interface portion of a webpage from the business logic.
Have all UI related code in .aspx file and the business logic in .cs file and then link these two files using the page directive in the ASPX page.

General Page Life-cycle Stages (SILVER U)
Page life cycle begins after the “Page request” is begins
Start -> Request and Response are set. Sets the IsPostBack & UICulture property value.
Page Initialization -> Controls are available(but control values are not reloaded from viewstate).Any themes are also applied to the page
Load -> Control properties are loaded with information recovered from
view state and control state.
Validation -> sets the IsValid property of individual validator controls and of the page.
Postback Event handling -> any event handlers are called.
Rendering -> Before rendering, view state is saved for the page and all controls.During the rendering phase, the page calls the Render method for each control,
providing a text writer that writes its output to the OutputStream of the page’s Response property.
Unload -> Unload is called after the page has been fully rendered, sent to the client, and is ready to be discarded. At this point, page properties such as Response and Request are unloaded and any cleanup is performed.

Life-cycle Events
Within each stage of the life cycle of a page, the page raises events that you can handle to run your own code.
PreInit -> Check the IsPostBack property to determine whether this is the first time the page is being processed. Create dynamic controls, set master /theme / profile property dynamically.
Init-> Used to read or initialize control properties.
InitComplete -> Use this event for processing tasks that require all initialization be complete.
PreLoad -> Use this event if you need to perform processing on your page or control before the Load event. You can add logic to do localization and view security here.
Load -> Calls OnLoad event method on the Page, then recursively for each child control. Use the OnLoad event method to set properties in controls and establish database connections
Control events -> Use these events to handle specific control events, such as a Button control’s Click event etc.
LoadComplete -> Use this event for tasks that require that all other controls on the page be loaded
PreRender -> The PreRender event occurs for each control on the page. Use the event to make final changes to the contents of the page or its controls.
SaveStateComplete -> Before this event occurs, ViewState has been saved for the page and for all controls. Any changes to the page or controls at this point will be ignored.
Render -> the Page object calls this method on each control. (This is not an event). A user control (an .ascx file) automatically incorporates rendering, so you do not need to explicitly render the control in code.
Unload -> This event occurs for each control and then for the page. In controls, use this event to do final cleanup for specific controls, such as closing control-specific database connections.
For the page itself, use this event to do final cleanup work, such as closing open files and database connections, or finishing up logging or other request-specific tasks.

Compilation Life Cycle
ASP.NET compiles application items in a specific order

App_GlobalResources
App_WebResources
Web.config file
App_Code
Global.asax
App_LocalResources
Individual Web pages (.aspx files), user controls (.ascx files), HTTP handlers (.ashx files),
and HTTP modules (.asmx files)
Themes, master pages, other source files

Compiled assemblies are cached on the server and reused on subsequent requests

Login Control Events
The Login control can use settings in the Web.config file to manage membership authentication automatically
LoggingIn , Authenticate, LoggedIn, LoginError

Whats the difference between Page_Load and Page_Init events?
Ans. The Page_load event assures that all controls are completely loaded and Viewstate is complete.
Even though the controls are also accessible in Page_Init event but here the viewstate is incomplete.

Whats the difference between Web.config and Machine.Config in .NET?
Ans. Web.config file is used to make the settings to a web application, whereas
Machine.config file is used to make settings to all ASP.NET applications on a server machine.

Whats the difference between web.config and app.config?
Ans. Web.config is used for web based asp.net applications whereas
app.config is used for windows based applications.

Whats the difference between a session object and an application object?
Ans. A session object can persist information between HTTP requests for a particular user, whereas
an application object can be used globally for all the users.

Whats the difference between DOM parser & SAX parser? when to use what?
Ans. The DOM Approach is useful for small documents in which the program needs to process a large portion of the document whereas
The SAX approach is useful for large documents in which the program only needs to process a small portion of the document.

REQUEST is the message that the browser sends to the server and
RESPONSE is the message the server sends back to the browser.

Assume you have PAGE1.ASPX ->
——————————–
RESPONSE.Redirect(“PAGE2.ASPX”);
SERVER.Tranfer(“PAGE2.ASPX”);

means,
RESPONSE.Redirect -> When Server receives this statement from browser,
It immediately sends a command back to the browser
to request PAGE2.ASPX from the server.

This extra round-trip is often inefficent and unnecessary.
NOTE: Roundtrip is the combination of a request being sent to
to the server and response being sent back to browser.

URL in the address bar in the browser will show PAGE2.ASPX

By the time PAGE2 is requested, PAGE1 has been flushed from the
server’s memory.
Therefore PAGE2 cannot accesses PAGE1 data
To achive this developer has to explicity save the information
using some technique like
Session/Cookies/Cache/Application etc at server end.

SERVER.Transfer -> When server receives this statement from browser,
It just sends PAGE2.ASPX to the browser.
No extra round trip occurs.

Here the PAGE1 data will be available in the scope of PAGE2.
(OR) PAGE1 data is forwarded to PAGE2. PAGE2 accesses PAGE1 data.

URL in the address bar in the browser will not change and
still show PAGE1.ASPX

The PROBLEM here is – say the user reloads the page, the browser
will request PAGE1.ASPX instead of the true page (PAGE2.ASPX)
that he was viewing.

OUTER Join – returns BOTH matching and non-matching rows from both tables

LEFT Outer Join – returns all the rows from the table on the LEFT side of JOIN keyword
+ returns the matching rows from both tables
Ex.query always contains all records of the “left” table (A), even if the join-condition does not find any matching record in the “right” table (B).

RIGHT Outer Join -returns all the rows from the table on the RIGHT side of JOIN keyword
+ returns the matching rows from both tables

FULL Outer Join – returns all the rows from both tables.

SELF Join – A table joining to itself.

CROSS Join – used to return the cartesian product of the tables included in the join condition. If A and B are two sets, then the result of cross join is written as A × B.
————————————————-
EXAMPLE:
INNER JOIN
SELECT * FROM employee INNER JOIN department ON
employee.DepartmentID = department.DepartmentID
is similar to
SELECT * FROM employee, department WHERE
employee.DepartmentID = department.DepartmentID
————————————————-
LEFT OUTER JOIN
SELECT * FROM employee LEFT OUTER JOIN department ON
employee.DepartmentID = department.DepartmentID
————————————————-
RIGHT OUTER JOIN
SELECT * FROM employee RIGHT OUTER JOIN department ON
employee.DepartmentID = department.DepartmentID
————————————————-
FULL OUTER JOIN
SELECT * FROM employee FULL OUTER JOIN department ON
employee.DepartmentID = department.DepartmentID
————————————————-
CROSS JOIN
SELECT * FROM employee CROSS JOIN department
————————————————-
SELF JOIN
SELECT F.EmployeeID, F.LastName, S.EmployeeID, S.LastName, F.Country
FROM Employee F, Employee S
WHERE F.Country = S.Country
AND F.EmployeeID < S.EmployeeID
ORDER BY F.EmployeeID, S.EmployeeID;
————————————————-