Wednesday, September 24, 2008

RELATIONSHIP BETWEEN OBJECTS

Association
In an object-oriented solution, we find an organisation of objects, each object playing a
set of roles and each role handling a set of responsibilities.
Playing a role, a person has some contract with the external world to provide a set of
services. A taxicab driver plays his role and is responsible to ply passenger for a fair
fixed by the authorities. If a person approaches a taxi in a stand or calls one by radio, the
taxi cab driver or taxi company is obliged to transport the person from the origin to a
desired destination. To request for the services of a taxicab, we have to associate with the
taxi driver by making eye contact or calling him over a phone. We cannot request a
service from an entity before establishing a contact, i.e., before forming an association .
In the society, an entity implicitly or explicitly announces the services offered by it. An
object, which is a model of a real world entity, exposes its interfaces announcing to other
objects the services it offers. Viewing differently, the interfaces announce the
responsibilities of an object. Another object in the application that can establish an
association with this object can send a message (aka request) requesting the object for
some services.
Thus, association between two objects is necessary before they can communicate with
each other. When an object sends a message to a second and for its own behavior
depends on the resulting state of the second object that has acted on the request or the on
the value returned, there is a dependency by the first object on the second.

Whole-Part Relationship – A Special Type of Association
In an association, an object seeks services of another object to achieve a result that it
could not have achieved on its own. But, the modeling of the object itself is complete.
When an object’s own definition does not structurally depend on the associated object,
but has a reference to the other object, we call the relationship as association.
There are several cases where we build an object by assembling other objects. We form a
whole by using different parts, though the parts themselves may be useful as independent
objects. A taxicab has parts like steering system, braking system, engine, body, wheels
etc. To behave like a taxicab, it needs all the parts. For the cab to move faster, the engine
has to accelerate. A passenger asks the driver to move faster or slower; the taxi sends a
message through the accelerator pedal to the engine to rotate faster or slower. We don’t
say that the engine is rotating faster, but that the car is speeding. Seen from outside, we
see the whole object, and the parts are hidden. The structure and behavior of the whole
depends on the parts. When a behavior is requested, the whole delegates the
responsibility to appropriate parts.
The whole is aware of its parts as it requests for different services from the parts. A part
need not be aware of the whole. It would respond to the requests from the whole. Being
part of the whole, and not being visible to other objects, it receives requests only from the
whole whose part it is.
Whole-part relationships are classified as ‘aggregation’ and ‘composition ’ based on how
closely the parts relate to the whole.

Aggregation
When the parts are not created for the sake of whole and can be interchanged during the
life of the whole, it is aggregation. The parts could be manufactured separately and
assembled to create the whole. Parts of an automobile are manufactured separately and
are changed during the life of the vehicle. Also, a part may be used with another whole –
Explaining Object Oriented Analysis Concepts to Managers of an Organization
19
a wheel that is used in a car may be used in a bullock cart too( Seven years ago, I went to
buy a tyre for my Maruti car. The sh op keeper asked if I needed the tyre for a bullock
cart. He said that no tax would be levied on this purchase, if it was for a bullock cart).
In some cases, a part may be shared by several whole objects simultaneously. If we
consider a sports team with several players, these players may be members of several
teams at a time. Several computers may share one monitor. It is possible to use a TV set
as a TV receiver and an AV player for DVD.
As the parts are not created for the sake of whole and also may be shared, the whole does
not have the responsibility of creating the parts and does not have right to delete the parts.
The whole does not own its parts.

Composition
Composition is a special kind of aggregation.
The tyre of a car is manufactured using steel re-enforcer and rubber. We do not
recompose the parts during the use of the tyre nor do we separate the parts after it is
manufactured. When we compose a word, we use several characters and when the word
is deleted all the characters in the word are also deleted. In composition, the parts are
created for the whole and are deleted with the whole.
In a composition relationship, the whole owns its parts; it has the responsibility to create
and delete the parts. Hence, the parts cannot be shared with other whole objects.
Model of a whole-part relationship (aggregation Vs. composition) depends on the domain
and context. E.g., for an end user, a laptop computer would be composed of its parts and
a desktop computer aggregation of its parts. For a manufacturer of the PCs, laptop and
desktop computer both would be aggregation.

Inheritance
Often we use words in a way that the meaning of one concept is part of another. If we say
that a person travels by an automobile, the meaning does not change if he travels by a car,
bus, or any other automobile vehicle. In our thought process, we use a grouping
mechanism to understand and use concepts. This is a way of knowing something new in
terms of something we know. What we already know has the essential features to
represent the concept at that level. Without this process we could not build knowledge.
When we “buy vegetables, fruits, groceries, and clothes” we have generalized some
concepts.
When we say that a car is an automobile, we understand that all the structural and
behavioral properties of the concept of automobile are applicable to a car. We do not
have to define and understand these concepts again. This simplifies our understanding
and communication. The car can have some additional property, uncommon to other
automobiles. It is easier to say that a car is a special kind of automobile having all the
properties of a common automobile and some stated additional features. This extends the
concept of an automobile. When we define a bus, again we can use the already defined
model of automobile and add features specific to a bus.
When we define a new concept in terms of already understood concepts, we inherit the
features of the previously known concept and specialize it by adding some new features.
As we have inherited some features of the existing model, should there be some changes
to the original concepts, it would affect all the specialized concept too. E.g., if the
concept of automobile assumed it to run on IC engines, all the inherited vehicles would
Dinesha and Bhat
20
also have IC engines – not battery powered motors to move them. If there be a change in
the concept of automobiles to change from IC engine to electrical motors, it would affect
all the inherited concepts.
With inheritance we can define a new concept in terms of already known concepts, which
helps build knowledge incrementally, reusing existing knowledge/model.
Contrast this with association where we use another object by knowing its responsibilities
and interfaces.

Tuesday, September 23, 2008

Inside IIS and ASP.NET

Introduction
Tools like ASP.NET greatly simplify the development of a complex Web application. Although this is a great thing for general productivity, it can also keep you from understanding the fundamental communications between your Web server and your ASP.NET application code. Furthermore, there will be times when you need to butt-in and intercept HTTP requests, which requires a greater understanding of the process of communication between your Web server of choice, and ASP.NET.
This article explains how IIS and ASP.NET communicate, and describes some techniques for intercepting some of this communication. I’ll review how ASP.NET is configured to handle requests, and how applications and Web services are handled by default.
Then I’ll discuss how you might butt-in to those requests with HTTP handlers, handler factories and modules. You’ll see how they function individually and together through a series of examples.

From IIS to ASP.NET
IIS communicates with the .NET framework through unmanaged ISAPI extensions: aspnet_isapi.dll and aspnet_filter.dll. The aspnet_isapi.dll is an extension that serves as a request router, and the aspnet_filter.dll is a filter that primarily handles cookieless session states for ASP.NET. These unmanaged components, along with the state Windows service (aspnet_state.exe) and the ASP.NET worker process (aspnet_wp.exe) are the core of the ASP.NET processing model.
When the .NET framework is installed on a machine that has IIS installed, IIS is configured so that requests for specific extensions are handled by aspnet_isapi.dll. As a point of interest, the filter is also configured within IIS..

Requests for ASP.NET resources are forwarded by IIS to ASP.NET via this configured extension. This extension is the bridge between unmanaged and managed code. Before control is passed to your application, an ASP.NET application object must be instantiated (by the runtime) and configuration settings are considered to determine how this request should be handled. Machine.config and collective web.config files are processed collectively to support this process.

For this article, we are specifically interested in the configuration section. Settings in this section indicate which .NET type should handle the request. The default settings found in the machine.config file when .NET is installed, are as follows:

The <httpHandlers> section indicates which HTTP handler factory, or handler, should be used to handle the request. In summary, the high-level workflow from IIS to your ASP.NET applications is as follows:
•IIS receives request for a resource
•For resources mapped to ASP.NET ISAPI Extension (i.e., *.aspx, *.asmx) the request is passed to an unmanaged ASP.NET DLL which communicates with the HttpRuntime object
•The HttpRuntime object handles creation of the HttpApplication object (as needed), and the inspection of configuration settings, then passes control to the appropriate handler for the request
•The handler is created to process request, which ultimately sends a response
The following diagram illustrates this workflow:

<httpHandlers> settings can be modified at the global (machine.config) level, or overridden at the application (web.config) level. In other words, you can specify a different factory or handler to process particular resource requests. For example, to reject requests for *.rem objects, you can edit the machine.config, or the application web.config as follows:

HTTP Handlers and Handler Factories
As mentioned above, the ASP.NET runtime relies on HTTP handlers or handler factories to process requests. Configuration file settings associate an HTTP handler or handler factory class with specific resources. Let’s take a closer look at these settings.
The following entry associates the System.Web.UI.PageHandlerFactory class with *.aspx resources, for all HTTP verbs (i.e., GET, POST):

This next entry associates System.Web.HttpForbiddenHandler with *.config resources:

These are preexisting classes provided with the base class library, but you can also build custom handlers and handler factories, by implementing the IHttpHandlerFactory and IHttpHandler interface (respectively). Before we talk about how to implement custom handlers and factories, let’s review their features. From a high level, HTTP handler factories are specified in order to dynamically return the correct HTTP handler object to manage the requested resource. If an HTTP handler is specified, it is instantiated directly by the runtime. Regardless, the end-result is to invoke a handler for the resource.
After the runtime passes control to a handler, it is the handler’s job to handle the request, instantiating the appropriate ASP.NET server-side objects, and send an HTTP response. For example, PageHandlerFactory returns a System.Web.UI.Page object for the requested *.aspx resource, and System.Web.HttpForbiddenHandler throws an HttpException indicating that the request is not supported.

Implementing IHttpHandler
Similar to ISAPI extensions, handlers provide low-level access to HTTP request and response objects. Implementing a custom handler allows you to process specific resources differently. You can intercept requests for those resources and override the response. For example, if you wanted to log the IP addresses of those requesting forbidden files, you could write a handler that logged information about those requests before throwing an HttpException. You may even want to send back a little love note to those making such request, as shown in the sample code, like this:

To create a custom HTTP handler, create a .NET component that implements IHttpHandler. This interface has the following members:
ProcessRequest() – this method is invoked by the runtime to handle the request
IsReusable – this property indicates if multiple requests can share the same handler
ProcessRequest() is passed the HttpContext for the request, which can be used to access HttpRequest, HttpResponse and HttpSessionState objects.
NOTE: A handler must implement IRequiresSessionState if it will access the session object.
Here is a simple example of an HTTP handler that writes output to the browser:

public class ForbiddenLogHandler: IHttpHandler
{
public ForbiddenLogHandler()
{
}

public virtual void ProcessRequest(HttpContext context)
{
context.Trace.Write("ForbiddenLogHandler.ProcessRequest()");
HttpResponse rs = context.Response;
HttpRequest rq = context.Request;
rs.Write("

We know who you are...

");
rs.Write("You were referred by " + rq.UrlReferrer + "
");
rs.Write("Your IP is" + rq.UserHostAddress + "
");
rs.Write("Your domain is" + rq.UserHostName + "
");
rs.Write("

Why were you requesting a restricted resource?

");
}
public virtual bool IsReusable
{
get { return true; }
}
}

The following web.config section configures the ForbiddenLogHandler for any *.cs, *.resx, or *.config files within the application:

<httpHandlers>
<add verb="*" path="*.cs" type="WebHandlers.ForbiddenLogHandler,WebHandlers"/>
<add verb="*" path="*.resx" type="WebHandlers.ForbiddenLogHandler,WebHandlers"/>
<add verb="*" path="*.config" type="WebHandlers.ForbiddenLogHandler,WebHandlers"/>
</httpHandlers>

Implementing IHttpHandlerFactory
Where HTTP handlers may be useful in responding to requests for specific resources, a handler factory makes it possible to intercept a request, perform some pre-processing on the request, and then following a factory pattern, create the handler for the resource.
To create a custom handler factory, create a .NET component that implements IHttpHandlerFactory. This interface has the following members:
GetHandler() – wadda ya know, this method returns a valid IHttpHandler for the runtime to process the requested resource
ReleaseHandler() – provides an opportunity for the factory to reuse a handler
GetHandler() is called by the runtime, and must return null, or a valid IHttpHandler. Here is an example of an HTTP handler factory that counts the number of hits from a particular IP address, if the count is exceeded, returns a custom handler, if not, passes control to the default handler for the resource.

public class HitTrackingHandlerFactory: IHttpHandlerFactory
{
public HitTrackingHandlerFactory()
{
}

public virtual IHttpHandler GetHandler(HttpContext context, String requestType, String url, String pathTranslated)
{

if (!HitLogHelper.CheckHitCount(context.Request.UserHostAddress, context.Request.UserHostName))
return new HitsExceededHandler();
Object handler = null;
try {
String filename = url.Substring(url.LastIndexOf('/')+1);
String file = filename.Substring(0, filename.IndexOf('.'));
String ext = filename.Substring(filename.LastIndexOf('.')+1);

if (ext == "aspx")
{
return System.Web.UI.PageParser.GetCompiledPageInstance(url, pathTranslated, context);
}
else if (ext == "asmx")
{
System.Web.Services.Protocols.WebServiceHandlerFactory fact = new System.Web.Services.Protocols.WebServiceHandlerFactory();

handler = fact.GetHandler(context, context.Request.RequestType, url, pathTranslated);
}
else if (ext == "rem")
{
System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory fact = new System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory();
handler = fact.GetHandler(context, context.Request.RequestType, url, pathTranslated);
}
else
{
throw new HttpException("Unable to process extension *." + ext);
}

}
catch (Exception e)
{
throw new HttpException("HitTrackingHandlerFactory", e);
}
return (IHttpHandler)handler;
}

public virtual void ReleaseHandler(IHttpHandler handler)
{
return;
}
}

public class HitsExceededHandler: IHttpHandler
{
public HitsExceededHandler()
{
}

public virtual void ProcessRequest(HttpContext context)
{
context.Response.Write("

Number of hits exceeded!

");
}

public virtual bool IsReusable
{
get { return true; }
}
}
Implementing IHttpModule
A module provides an event-driven mechanism for interacting with application events, and HTTP request and response objects. Registered modules are instantiated before HTTP handlers and handler factories, so that they can register for application events. In fact, modules interact with Web applications in two ways: by listening to application events, and by firing custom events to applications that have registered to listen. The latter of these two tightly couples the module with your application. The former provides access to the request, response, and session objects at various stages in the processing of each HTTP request, in an independent component.
To create a custom module, create a .NET component that implements IHttpModule. This interface has the following members:
Init() – provides an opportunity for modules to register for application events
Dispose() – provides an opportunity to clean up resources allocated by
The following sample Init() method registers for the HttpApplication object’s PreRequestHandlerExecute, PostRequestHandlerExecute, and Error events:

protected void Init()
{
application.PreRequestHandlerExecute += (new EventHandler(this.Application_PreRequestHandlerExecute));
application.PostRequestHandlerExecute += (new EventHandler(this.Application_PostRequestHandlerExecute));
application.Error += (new EventHandler(this.Application_Error));
}

You can also handle these events in individual applications in the global.asax, however using a module makes it possible to toggle the configuration externally, and deploy a common set of event handlers for multiple applications:

<httpModules>
<add name="EventModule" type="WebHandlers.EventModule,WebHandlers"/>
<add name="ErrorHandlerModule" type="WebHandlers.ErrorHandlerModule,WebHandlers"/>
</httpModules>

In such a global error handler, you could provide a catch all error handler that notifies the site administrator of uncaught exceptions.
Handlers vs. Modules
From an architectural perspective, handlers and modules serve a much different purpose. Handlers (and factories returning handlers) provide a way to intercept the request, and redirect how it is handled. The best a module can do in this respect, is send a custom response, and cancel the handler from completing its job. What they have in common is the ability to access to the underlying HttpApplication, HttpRequest, HttpResponse, and HttpSessionState objects (at certain points) so that you can manipulate and/or interact with this data.
The order of events for these components is as follows:

HttpApplication is created (if necessary)
HttpModules are created (in order of appearance in configuration files)
Modules will receive request notification and authentication events, prior to control passing to the appropriate handler.
HttpHandlerFactory/HttpHandler is created, to process the request
Resulting objects are created (I.e., the Page, Web Service or Remote object)
These objects, the application, and any modules continue to interact with one another via events

The following diagram illustrates the default behavior, in order of instantiation:

This next diagram illustrates where custom factories, handlers, modules and extensions would fit in the workflow:

The Code
Code samples supplied with this article demonstrate the order of events when custom handler factories, handlers and modules are all present. Code demonstrates the following:

The <trace> element of the web.config file is configured to display trace output in the Web page. When the page is loaded, you’ll be able to see trace statements, and you can also view the trace.axd file like so: http://localhost/ASPNETCS/WebResources/trace.axd
From the main Web page, you can click on invalid resources to see the results of the ForbiddenLogHandler, which handles *.resx, *.cs, and *.config requests.
A custom message is written to the response stream, but the data returned can also be interesting data to collect from those visiting your site, for data mining.
The main Web page also has a link to an invalid resource, which will generate an application error. The ErrorHandlerModule is configured to pick up errors, and e-mail the administrator a notification, while also writing custom HTML to the response stream.
After 2 passes though the HitTrackingHandlerFactory, you will no longer be able to browse the main page. An XML file is written by the factory, counting hits from particular IPs, and rejecting that IP after 2 hits. Note the file path is currently hard-coded, so you’ll need to create a directory for the file, and modify the code to match. Delete the file to reset the behavior. The factory also demonstrates forwarding the request to be handled by default behavior of ASP.NET configuration, if the request is approved.
Summary
This article should give you the tools you need to determine what architectural model is best for you application, with respect to intercepting HTTP requests, and modifying application behavior globally. For your reading pleasure, here are a few ideas:
Customize authentication, to provide a guest account for users that do not have permission
Pre-authenticate users for a “trial” usage of your application
Toggle logging behavior, to collect useful statistics about your clients, and perform data mining

Finalize vs Dispose in C#

-You cannot override the Finalize method in the C#, instead, you have to use destructor syntax to implement the Finalize method.

It is not legal to call a destructor explicitly. Your destructor will be called by the garbage collector. If you do handle precious unmanaged resources (such as file handles) that you want to close and dispose of as quickly as possible, you ought to implement the IDisposable interface. The IDisposable interface requires its implementers to define one method, named Dispose(), to perform whatever cleanup you consider to be crucial. The availability of Dispose() is a way for your clients to say, "Don’t wait for the destructor to be called; do it right now."
If you provide a Dispose() method, you should stop the garbage collector from calling your object’s destructor. To stop the garbage collector, you call the static method, GC.SuppressFinalize(), passing in this reference for your object. Your destructor can then call your Dispose() method. Thus, you might write:

using System;
class Testing : IDisposable
{
bool is_disposed = false;
protected virtual void Dispose(bool disposing)
{
if (!is_disposed) // only dispose once!
{
if (disposing)
{
Console.WriteLine("Not in destructor, OK to reference
other objects");
}
// perform cleanup for this object
Console.WriteLine("Disposing...");
}
this.is_disposed = true;
}
public void Dispose()
{
Dispose(true);
// tell the GC not to finalize
GC.SuppressFinalize(this);
}
~Testing()
{
Dispose(false);
Console.WriteLine("In destructor.");
}
}

Implementing the Close method
For some objects, you’d rather have your clients call the Close() method. (For example, Close makes more sense than Dispose() for file objects.) You can implement this by creating a private Dispose() method and a public Close() method and having your Close() method invoke Dispose().

The using statement
Because you cannot be certain that your user will call Dispose() reliably, and because finalization is nondeterministic (meaning you can’t control when the garbage collector will run), C# provides a using statement, which ensures that Dispose() will be called at the earliest possible time. The idiom is to declare which objects you are using and then to create a scope for these objects with curly braces. When the close brace is reached, the Dispose() method will be called on the object automatically:
using System.Drawing;
class Tester
{
public static void Main()
{
using (Font theFont = new Font("Arial", 10.0f))
{
// use theFont
} // compiler will call Dispose on theFont
Font anotherFont = new Font("Courier",12.0f);
using (anotherFont)
{
// use anotherFont
} // compiler calls Dispose on anotherFont
}
}

In the first part of this example, the Font object is created within the using statement. When the using statement ends, Dispose() is called on the Font object.
In the second part of the example, a Font object is created outside of the using statement. When we decide to use that font, we put it inside the using statement and when that statement ends, once again Dispose() is called.
The using statement also protects you against unanticipated exceptions. No matter how control leaves the using statement, Dispose() is called. It is as if there were an implicit try-catch-finally block.

Wednesday, September 17, 2008

Important Scenario for Abstract Class and Interface

Hi .Net lovers,I assume you all know what is an Abstract class and what is an Interface, and the question always comes in mind when to use-which:

The most important scenario of deciding when to use Abstract Class or an Interface comes by trying to establish an IS-A relationship (abstract class) or CAN-DO relationship (Interface) between the related objects.

1. Abstract Class e.g.A "Manager" IS AN "Employee" and a "BusinessAnalyst" IS ALSO AN "Employee"so for this relationship we can create an "Employee" Abstract class and the other classes "Manager" and "BusinessAnalyst" should derive from it and may provide their own implementations...........

2. Interface e.g.There will an annual appraisal for all types of Employees in an Organization. so, all Employees must establish a certain kind of contract to fulfill for Appraisal which is done by an "IAppraisal" interface which might have 2 methods - viz.

public void IncreaseGrade(); //The Manager will be promoted by a different Grade than other types of Employees

public void IncreaseSalary(double percentage); //The %age increase in Manager's Salary will be different (may depend on new Grade also) than other types of Employees

Hope this clarifies the scenario.Other aspects to decide are Versioning and Ease of Use (like the existing Abstract class provides some implementation and change in its implementation code does not cause the derived classes to recompile while a change in contract or interface causes the child class to be recompiled) between the two.

Ref: Applied Microsoft .Net Framework (Jeffrey Richter )Thanks,

Monday, September 15, 2008

Difference between function and stored proc

1>Procedure can return zero or n values whereas function can return one value which is mandatory.

2>Procedures can have input,output parameters for it whereas functions can have only input parameters.

3>Procedure allow select as well as DML statement in it whereas function allow only select statement in it.

4>Functions can be called from procedure whereas procedures cannot be called from function.

5>Exception can be handled by try-catch block in a procedure whereas try-catch block cannot be used in a function.

6>We can go for transaction management in procedure whereas we can't go in function.

7>Procedures can not be utilized in a select statement whereas function can be embedded in a select statement.

Sunday, September 14, 2008

Remote Debug .Net

To debug an XML Web service After Deployment, you need to take the help of DbgClr and execute below steps.
• Open the XML Web service in Internet Explorer by entering the URL for the .asmx file, such as http://localhost/MathService/MathService.asmx.
• From the Debug menu in Visual Studio .NET, choose Processes to open the Processes dialog box.
• Select aspnet_wp.exe from the Process list and click the Attach button, which opens the Attach To Process dialog box
• In the Attach To Process dialog box, select Common Language Runtime as the program type to debug and select the program that you want to debug, in this case MathService. Click OK, and then click the Close button to close the Processes dialog box.
• From the File menu in Visual Studio .NET, point to Open, and click File. In the Open File dialog box, select the code-behind file, such as the MathService.asmx.vb or MathService.asmx.cs file, located in the Inetpub\Wwwroot\MathService folder.
• Set breakpoint(s) in the code. In the MathService example, set a breakpoint on the line containing the divide method.
• In Internet Explorer, click the Divide link to display a new page where you can pass parameters to the divide method. Pass the values for the n1 and n2 parameters, and click the Invoke button.
• The debugger breaks the execution at the breakpoint set on the line containing the divide method.
• Use debug windows such as Autos, Locals, and Watch to examine the variables and their values.
• To stop debugging, choose Stop Debugging from the Debug menu.
Remote Debugging
To facilitate some of the remote debugging features required is - To install the Remote Debugging Components, insert the Visual Studio .NET setup disk into the target computer and select the Remote Components Setup link at the bottom of the opening screen.
Once installed, make sure that you have sufficient permissions to Attach to and Debug the target process on the remote machine. In order to simplify this process, Setup creates a local group on the target machine called Debugger Users. Users added to the Debugger Users group will have sufficient permissions to conduct a remote interactive debugging session. However, they also need permissions to attach to the
process itself.

One of the unique requirements for debugging Web services is strong support for remote debugging. The key features that Visual Studio .NET provides for supporting remote debugging include these:
• Visual Studio .NET automatically attaches to the remote ASP.NET process hosting the Web service.
• It allows you to configure the target server to allow remote debugging.
• It can display a logical call stack that spans multiple threads.
• It ensures that you get a complete call stack when an unhandled exception occurs within your application.