Tarik Guney's List: Programming

• the singleton pattern is a design pattern that is used to restrict instantiation of a class to one object.

• Lazy loading is a design pattern commonly used in computer programming to defer initialization of an object until the point at which it is needed. It can contribute to efficiency in the program's operation if properly and appropriately used. The opposite of lazy loading is Eager Loading.

• A static constructor is used to initialize any static data, or to perform a particular action that needs performed once only. It is called automatically before the first instance is created or any static members are referenced.
• A static constructor does not take access modifiers or have parameters.
• A static constructor is called automatically to initialize the class before the first instance is created or any static members are referenced.
• If a static constructor throws an exception, the runtime will not invoke it a second time, and the type will remain uninitialized for the lifetime of the application domain in which your program is running.

2 more annotations...

• Not to be confused with B-tree.

• Basic) methods for lazy init

• The XElement class (declared in System.Linq.XML) provides a Load method that can retrieve an XML data from a url with GET  method:

1 more annotation...

• Ajax is a popular term used to describe asynchronous (versus synchronous)  requests made from the client to the server. In JavaScript, Ajax requests  are handled using the XMLHttpRequest object, which lets you open a  connection, send the request, then handle the data returned by the server  seamlessly in the background.

• One unfortunate anti-pattern that often emerges in this situation is a service method with too many parameters:

• The better solution is to use inline ASP.NET code to inject the control’s ClientID property:
• $get('<%= TextBox1.ClientID %>')

• Creating anonymous methods is essentially a way to pass a code block as a delegate parameter

• If the asynchronous call has not completed, EndInvoke blocks the calling thread until it completes

• Most people are familiar only with the high level frameworks like WebForms and WebServices which sit at the very top level of the ASP.NET hierarchy.
• WebForms are definitely the easiest way to build most Web interfaces, but if you’re building custom content handlers, or have special needs for processing the incoming or outgoing content, or you need to build a custom application server interface to another application, using these lower level handlers or modules can provide better performance and more control over the actual request process. With all the power that the high level implementations of WebForms and WebServices provide they also add quite a bit of overhead to requests that you can bypass by working at a lower level.
• ASP.NET is a sophisticated engine using Managed Code for front to back processing of Web Requests.
• ASP.NET is a request processing engine.
• It takes an incoming request and passes it through its internal pipeline to an end point where you as a developer can attach code to process that request. This engine is actually completely separated from HTTP or the Web Server. In fact, the HTTP Runtime is a component that you can host in your own applications outside of IIS or any server side application altogether
• Through this mechanism it’s possible to hook into very low level interfaces such as the caching, authentication and authorization
• The entire ASP.NET engine was completely built in managed code and all  extensibility is provided via managed code extensions.
• the most impressive part of ASP.NET is the thoughtful design that makes the architecture easy to work with, yet provides hooks into just about any part of the request processing.
• ISAPI is a low level Win32 style API that had a very meager interface and was very difficult to work for sophisticated applications.
• ASP.NET on Microsoft platforms interfaces with IIS through an ISAPI extension that hosts .NET and through it the ASP.NET runtime. ISAPI provides the core interface from the Web Server and ASP.NET uses the unmanaged ISAPI code to retrieve input and send output back to the client. The content that ISAPI provides is available via common objects like HttpRequest and HttpResponse that expose the unmanaged data as managed objects with a nice and accessible interface.
• At the lowest level ASP.NET interfaces with IIS through an ISAPI extension.
• All of these HttpHandlers are mapped to point at the ASP.NET  ISAPI extension in IIS, and configured in web.config to get routed to a specific HTTP Handler implementation.
• an extension is the basic mapping mechanism that ASP.NET uses to receive a request from ISAPI and then route it to a specific handler that processes the request.
• ISAPI is very low level it’s not well suited for building application level code
• ISAPI tends to be used primarily as a bridge interface to provide Application Server type functionality to higher level tools
• In ASP and ASP.NET, the engines abstract the information provided by the ISAPI interface in the form of objects like Request and Response that read their content out of the ISAPI request information.
• All the heavy lifting and processing, and even the request thread management happens inside of the ASP.NET engine and your code.
• Extensions are a request handling interface and provide the logic to handle input and output with the Web Server – it’s essentially a transaction interface. ASP and ASP.NET are implemented as ISAPI extensions. ISAPI filters are hook interfaces that allow the ability to look at EVERY request that comes into IIS and to modify the content or change the behavior of functionalities like Authentication. Incidentally ASP.NET maps ISAPI-like functionality via two concepts: Http Handlers (extensions) and Http Modules (filters)
• Instead IIS 6 always creates a separate worker process – an Application Pool – and all processing occurs inside of this process, including execution of the ISAPI dll.
• Application Pools are a big improvement for IIS 6, as they allow very granular control over what executes in a given process. Application Pools can be configured for every virtual directory or the entire Web site, so you can isolate every Web application easily into its own process that will be completely isolated from any other Web application running on the same machine. If one process dies it will not affect any others at least from the Web processing perspective.
• Because Application Pools are external executables these executables can also be easily monitored and managed
• ISAPI extensions run in the Application Pool worker process. The .NET Runtime also runs in this same process, so communication between the ISAPI extension and the .NET runtime happens in-process which is inherently more efficient than the named pipe interface that IIS 5 must use
• The first entry point to the runtime is the undocumented ISAPIRuntime class which exposes the IISAPIRuntime interface via COM to a caller.
• The IISAPIRuntime interface acts as the interface point between the unmanaged code coming from the ISAPI extension (directly in IIS 6 and indirectly via the Named Pipe handler in IIS 5)
• The ecb parameter is the ISAPI Extension Control Block (ECB) which is passed as an unmanaged resource to ProcessRequest.
• To create the ISAPIRuntime instance the System.Web.Hosting.AppDomainFactory.Create() method is called when the first request for a specific virtual directory is requested
• This method in turn calls
• When a request hits, it is routed to the ISAPIRuntime.ProcessRequest() method.

• HttpRuntime.ProcessRequest that does several important things (look at System.Web.HttpRuntime.ProcessRequestInternal with Reflector):

    

   

    
   
  • Create  a new HttpContext instance for the request
   
  • Retrieves  an HttpApplication Instance
   
  • Calls HttpApplication.Init() to set up Pipeline Events
   
  • Init()  fires HttpApplication.ResumeProcessing() which  starts the ASP.NET pipeline processing
• First a new HttpContext object is created and it is passed the ISAPIWorkerRequest that wrappers the ISAPI ECB
• HttpContext  object represents the context of the currently active request as it contains references to all of the vital objects you typically access during the request lifetime: Request, Response, Application, Server, Cache. At any time during request processing HttpContext.Current gives you access to all of these object.
• The HttpContext object also contains a very useful Items collection that you can use to store data that is request specific. The context object gets created at the begging of the request cycle and released when the request finishes, so data stored there in the Items collection is specific only to the current request.
• The HttpApplication is like a master of ceremonies – it is where the processing action starts
• Each request is routed to an HttpApplication object.
• It’s the first entry point into the HTTP Runtime that you actually see on a regular basis in your applications.
• HttpApplication is the outer container for your specific Web application and it maps to the class that is defined in Global.asax.
• HttpApplication’s primary purpose is to act as the event controller of the Http Pipeline and so its interface consists primarily of events.
• It’s important to understand that each ASP.NET virtual application runs in its own AppDomain and that there inside of the AppDomain multiple HttpApplication instances running simultaneously, fed out of a pool that ASP.NET manages. This is so that multiple requests can process at the same time without interfering with each other.
• AppDomain ID stays steady while thread and HttpApplication Ids change on most requests
• HttpApplications are running out of a collection and are reused for subsequent requests so the ids repeat at times.
• Threads are served from the .NET ThreadPool and by default are Multithreaded Apartment (MTA) style threads
• The fact that these HttpApplication objects are all running in the same AppDomain is very important. This is how ASP.NET can guarantee that changes to web.config or individual ASP.NET pages get recognized throughout the AppDomain. Making a change to a value in web.config causes the AppDomain to be shut down and restarted. This makes sure that all instances of HttpApplication see the changes made because when the AppDomain reloads the changes from ASP.NET are re-read at startup. Any static references are also reloaded when the AppDomain so if the application reads values from App Configuration settings these values also get refreshed. 
• In essence the Web Application/Virtual completely ‘restarts’ when this happens. Any requests that are already in the pipeline processing will continue running through the existing pipeline, while any new requests coming in are routed to the new AppDomain. In order to deal with ‘hung requests’ ASP.NET forcefully shuts down the AppDomain after the request timeout period is up even if requests are still pending. So it’s actually possible that two AppDomains exist for the same HttpApplication at a given point in time as the old one’s shutting down and the new one is ramping up. Both AppDomains continue to serve their clients until the old one has run out its pending requests and shuts down leaving just the new AppDomain running.
• The HttpApplication is responsible for the request flow by firing events that signal your application that things are happening.
• Both HttpModules and HttpHandlers are loaded dynamically via entries in Web.config and attached to the event chain. HttpModules are actual event handlers that hook specific HttpApplication events, while HttpHandlers are an end point that gets called to handle ‘application level request processing’.
• The HttpApplication itself knows nothing about the data being sent to the application – it is a merely messaging object that communicates via events. It fires events and passes information via the HttpContext object to the called methods
• ASP.NET Page and Web Service frameworks are implemented as HTTPHandlers and that’s where all the core processing of the request is handled
• Modules allow you look at each incoming Web request and perform an action based on the events that fire. Modules are great to modify request or response content, to provide custom authentication or otherwise provide pre or post processing to every request that occurs against ASP.NET in a particular application.
• hile HttpModules feel similar to ISAPI Filters in that they look at every request in that comes through an ASP.NET Application, they are limited to looking at requests mapped to a single specific ASP.NET application or virtual directory and then only against requests that are mapped to ASP.NET. Thus you can look at all ASPX pages or any of the other custom extensions that are mapped to this application. You cannot however look at standard .HTM or image files unless you explicitly map the extension to the ASP.NET ISAPI dll by adding an extension as shown
• Watch out for one important gotcha with HttpModules and HttpApplication events: Response.End() or HttpApplication.CompleteRequest() will shortcut the HttpApplication and Module event chain.
• Modules are fairly low level and fire against every inbound request to the ASP.NET application. Http Handlers are more focused and operate on a specific request mapping, usually a page extension that is mapped to the handler.
• WebForms and WebServices are both implemented as Http Handlers, so there’s a lot of power wrapped up in this seemingly simplistic interface.
• Because the Context object is available to you, you get access to the Request, Response, Session and Cache objects, so you have all the key features of an ASP.NET request at your disposal to figure out what users submitted and return content you generate back to the client.
• Remember the Context object – it’s your friend throughout the lifetime of an ASP.NET request!

• Behind the scenes the ISAPIWorkerRequest manages sending the OutputStream back into the ISAPI ecb.WriteClient method that actually performs the IIS output generation.

    

   
• 
• So handlers are more efficient. Handlers also can do things that aren’t possible with WebForms such as the ability to process requests without the need to have a physical file on disk, which is known as a virtual Url
• To do this make sure you turn off ‘Check that file exists’ checkbox in the Application Extension dialog shown in Figure 1.
• • IIS  gets the request
   
  • Looks  up a script map extension and maps to aspnet_isapi.dll
   
  • Code  hits the worker process (aspnet_wp.exe in IIS5 or w3wp.exe in IIS6)
   
  • .NET  runtime is loaded
   
  • IsapiRuntime.ProcessRequest() called by non-managed  code
   
  • IsapiWorkerRequest created once per request
   
  • HttpRuntime.ProcessRequest() called with Worker  Request
   
  • HttpContext Object created by passing Worker Request  as input
   
  • HttpApplication.GetApplicationInstance() called with  Context to retrieve instance from pool
   
  • HttpApplication.Init() called to start pipeline event sequence  and hook up modules and handlers
   
  • HttpApplicaton.ProcessRequest called to start  processing
   
  • Pipeline  events fire
   
  • Handlers  are called and ProcessRequest method are fired
   
  • Control  returns to pipeline and post request events fire

57 more annotations...

• The same-origin policy prevents  a script loaded from one domain from getting or manipulating properties of  a document from another domain. That is, the domain of the requested URL  must be the same as the domain of the current Web page. This basically  means that the browser isolates content from different origins to guard  them against manipulation. This browser policy is quite old and dates back  to Netscape Navigator 2.0.

• One relatively simple way to overcome  this limitation is to have the Web page request data from the Web server  it originates from, and to have the Web server behave as a proxy relaying the  request to the actual third-party servers. Although widely used, this  technique isn't scalable. Another way is to use frame elements to create  new areas in the current Web page, and to fetch any third-party content  using GET requests. After being fetched, however, the  content in the frames would be subject to the same-origin policy limitations.

     

  A  more promising way to overcome this limitation is to insert a dynamic  script element in the Web page, one whose source is pointing to the service  URL in the other domain and gets the data in the script itself. When the  script loads, it executes. It works because the same-origin policy doesn't  prevent dynamic script insertions and treats the scripts as if they were  loaded from the domain that provided the Web page. But if this script  tries to load a document from yet another domain, it will fail.  Fortunately, you can improve this technique by adding JavaScript Object  Notation (JSON) to the  mix.
• In the example in Listing 3, the dynamically inserted JavaScript code, residing in  the file ticker.js, calls the showPrice()  function using the actual JSON data as a parameter.
• n the example in Listing 3, the dynamically inserted JavaScript code, residing in  the file ticker.js, calls the showPrice()  function using the actual JSON data as a parameter.
• Note that,  in order to do this, you must have a callback function already defined  in the Web page at the time of insertion, which is showPrice() in our example.
• (JSON with Padding) is: JSON data wrapped in a function call.
• What we call a JSONP service  (or a Remote JSON Service), however, is a Web service with the additional  capability of supporting the wrapping of the returned JSON data in a user-specified function call. This approach relies on the remote service  accepting a callback function name as a request parameter. It then  generates a call to this function, passing the JSON data as parameter,  which upon arrival at the client is inserted into the Web page and  executed.

5 more annotations...