1. What is a Delegate?
    When we talk about delegates in .NET then one thing that comes to our mind is what delegate means to a novice developer. In simple words we can say delegates are a .NET object which points to a method that matches its specific signature.

    In other words delegates are function pointers that point to function of matching signatures. Function pointers which are extensively used in c/c++ to points to a function holds only the memory address of the function, it doesn’t carry further information about the function parameters, return type etc. On the other hand .NET framework has introduced a type-safe mechanism called delegates, with automatic verification of the signature by the compiler.

    So comparatively delegates add a safety dimension in handling function pointers in .NET.
    So we can say that delegates are type-safe, object oriented, secure .NET objects which can be used to invoke methods of matching signature.

    While using delegates it is very much necessary to make sure that the functions which the delegates points has the same number of argument type and same return type. For example if we have a method that takes a single string as a parameter and another method that takes two string parameters, then we need to have two separate delegate type for each method.

    Types of Delegate:

    Single cast delegate
    A delegate is called single cast delegate if it invokes a single method. In other words we can say that SingleCast Delegates refer to a single method with matching signature. SingleCast Delegates derive from the System.Delegate class

    SingleCast Delegates can be defined using the following syntax:

    public delegate int mySingleCastDelegate int iFirstargument, int iSecondArgument);

    Single cast delegate example:

    using System;
    namespace SingleCastDelegateDemoApplication
    {
    class mySingleDelegateClass
    {
    public delegate int mySingleCastDelegate(int iFirstargument,
    int iSecondArgument);
    static void Main(string[] args)
    {
    mySingleDelegateClass clsSingleCastDelegate = new mySingleDelegateClass();
    mySingleCastDelegate singleCastMaxNumberDelegate =
    new mySingleCastDelegate(clsSingleCastDelegate.myMaxFunction);
    int iMaxNumberResult = singleCastMaxNumberDelegate(10, 20);
    Console.WriteLine(@"Result by calling the myMaxFunction method using a
    delegate: {0}", iMaxNumberResult);
    Console.Read();
    }
    public int myMaxFunction(int iFirstNumber, int iSecondNumber)
    {
    if (iFirstNumber > iSecondNumber)
    return iFirstNumber;
    else
    return iSecondNumber;
    }
    }
    }


    Multicast Delegates:
    MultiCast Delegates are nothing but a single delegate that can invoke multiple methods of matching signature. MultiCast Delegate derives from System.MulticastDelegate class which is a subclass of System.Delegate.

    In Multi-Casting basically we create a single delegate that in turn invokes multiple encapsulated methods. We can use MultiCast Delegates when multiple calls to different methods are required. For example if we are required to call two methods on a single button click event or mouse over event then using MultiCast Delegates we can easily call the methods.

    The System.MulticastDelegate class provides required methods to play with delegates. There are two methods, Combine and Remove, which are used to play with delegates.

    The Combine method is a static method of System.MulticastDelegate class which is used to combine the delegates and the Remove method is used to remove the delegate from the list.
    The Combine method takes an array of delegate as a parameter and returns a new delegate that represents the combination of all the delegates in the array.

    MultiCast Delegate can have arguments and can have return values as well. The only things is that the methods pointed by delegate needs to have same return type as that of the return type of delegate.

    In the below code snippet I have defined a delegate which can act as a multicast delegate to encapsulate methods that takes two parameter as of type integer and returns nothing.

    public delegate void MyMulticastDelegate(int p, int q);

    Multi cast delegate example:

    using System;
    namespace MultiCastDelegatesDemoapplication
    {
    class MultiCastDelegatesClass
    {
    //delegate declaration
    Public delegate void MyMulticastDelegate(int p, int q);
    static void Main(string[] args)
    {
    MultiCastDelegatesClass clsMultiCastDelegate =
    new MultiCastDelegatesClass();
    MyMulticastDelegate myDelegate = null;
    MyMulticastDelegate myMultiCastDelegateAddition =
    new MyMulticastDelegate(clsMultiCastDelegate.myAddtionfunction);
    MyMulticastDelegate myMultiCastDelegateMaxNumber =
    new MyMulticastDelegate(clsMultiCastDelegate.myMaxFunction);
    Console.WriteLine("Used Combine function to bind the delegates... ");
    myDelegate = (MyMulticastDelegate)System.Delegate.Combine(myMultiCastDelegateAddition,
    myMultiCastDelegateMaxNumber);
    //call made using the multicast delegate
    myDelegate(10, 23);
    Console.WriteLine();
    Console.WriteLine(@"Used Remove function to remove the delegate from
    the list.. ");
    myDelegate = (MyMulticastDelegate)System.Delegate.Remove(myDelegate,
    myMultiCastDelegateMaxNumber);
    myDelegate(10, 23);
    Console.Read();
    }
    //function calculates the sum of passed arguments
    public void myAddtionfunction(int iFirstNumber, int iSecondNumber)
    {
    int result = iFirstNumber + iSecondNumber;
    Console.WriteLine(@"In myAddtionfunction called by a multi cast delegate:
    Result is :" + result);
    }
    //function checks the max value of passed arguments
    public void myMaxFunction(int iFirstNumber, int iSecondNumber)
    {
    int max ;
    if (iFirstNumber > iSecondNumber)
    {
    max = iFirstNumber;
    }
    else
    {
    max = iSecondNumber;
    }
    Console.WriteLine(@"In myMaxFunction called by a multi cast delegate:
    Result is :" + max);
    }
    }
    }

    0

    Add a comment

  2. Introduction:
    ASP.NET webforms provide excellent event driven programming model to developers. This does simplifies the overall design of your application but poses some problems of its own. For example, in traditional ASP you can easily pass values from one ASP page to another ASP page using POST. The same thing is not possible in ASP.NET if you want to stick to web form model (i.e. Server side form and control processing.). There are, however, some ways that can be used to overcome this situation. This article examines various possibilities to do the same. More specifically we will cover how to pass values using querystring, how to use session variables to do the same and finally how to use Server.Transfer method to do that.

    Using Querystring:

    Querystring is a day old mechanism to pass values across pages. The main advantage of this method is it is very simple. However, disadvantages are the values are visible in the browser address bar and you can not pass objects this way. This method is best suited when you want to pass small number of values that need not be secured from others. In order to implement this method you will follow these steps:
    • Create the web form with controls.
    • Provide some button or link button that posts the form back.
    • In the click event of the button create a string that holds URL for another.
    • Add control values to this URL as querystring parameters .
    • Response.Redirect to another form with this URL.

    Following code snippet shows how it works:

    Source Web Form:

    private void Button1_Click
    (object sender, System.EventArgs e)
    {
    string url;
    url="anotherwebform.aspx?name=" +
    TextBox1.Text + "&email=" +
    TextBox2.Text;
    Response.Redirect(url);
    }

    Destination Web Form:

    private void Page_Load
    (object sender, System.EventArgs e)
    {
    Label1.Text=Request.QueryString["name"];
    Label2.Text=Request.QueryString["email"];
    }

    Using Session variables:

    This is yet another way to pass values across pages. Here you store control values in session variables and access them in another web form. However, as you know storing too much data in session can be an overhead on the server. So, you should use this method with care. Also, it requires some kind of clean up action from your side so that unwanted session variables are removed. The typical sequence of steps will be as follows:

    • Create the web form with controls.
    • Provide some button or link button that posts the form back.
    • In the click event of the button add session variables and set them to control values.
    • Response.Redirect to another form.
    • In that form access Session variables and remove them if necessary.

    Following code shows this in action:

    Source Web Form:

    private void Button1_Click
    (object sender, System.EventArgs e)
    {
    //textbox1 and textbox2 are webform
    //controls
    Session["name"]=TextBox1.Text;
    Session["email"]=TextBox2.Text;
    Server.Transfer("anotherwebform.aspx");
    }

    Destination Web Form:

    private void Page_Load
    (object sender, System.EventArgs e)
    {
    Label1.Text=Session["name"].ToString();
    Label2.Text=Session["email"].ToString();
    Session.Remove("name");
    Session.Remove("email");
    }

    Using Server.Transfer:

    This is somewhat complex but sophisticated method of passing values across pages. Here you expose the values you want to access in other pages as properties of the page class. This methods require you to code extra properties that you can access in another web form. However, the efforts are worth considering. Overall this method is much cleaner and object oriented than earlier methods. The entire process works as follows:

    • Create the web form with controls.
    • Create property Get procedures that will return control values.
    • Provide some button or link button that posts the form back.
    • In the button click event handler call Server.Transfer method that will transfer execution to the specified form.
    • In the second form you can get a reference to the first form instance by using Context.Handler property. Then you will use the get properties we created to access the control values.

    Source Web Form:

    public string Name
    {
    get
    {
    return TextBox1.Text;
    }
    }
    public string EMail
    {
    get
    {
    return TextBox2.Text;
    }
    }

    Now, call Server.Transfer.

    private void Button1_Click (object sender, System.EventArgs e)

    {

    Server.Transfer("anotherwebform.aspx");

    }

    Destination Web Form:

    private void Page_Load
    (object sender, System.EventArgs e)
    {
    //create instance of source web form
    WebForm1 wf1;
    //get reference to current handler instance
    wf1=(WebForm1)Context.Handler;
    Label1.Text=wf1.Name;
    Label2.Text=wf1.EMail;
    }


    0

    Add a comment

  3. Just like with golf, technology is as much about ensuring that your bad hits are recoverable as it is ensuring that you make great ones. We’re all going to have failures in our careers but avoiding the really big pitfalls will help you keep your company on the right growth path. Here are 10 common mistakes we at AKF Consulting see made during platform development — and the ones we believe are the most important to avoid.

    1) Failing to design for rollback:

    If you’re developing a SaaS platform and you can only make one tweak to your current process, make it so that you can always roll back any code changes. We know that it takes additional engineering work and testing but in our experience, such effort yields the greatest ROI.

    2) Confusing product release with product success:

    Do you have “release” parties? Don’t — you are sending your team the wrong message. A release has little to do with creating shareholder value. Align your celebrations with achieving specific business objectives, such as increasing sign-ups by 10 percent.

    3) Assuming a new Product Development Lifecycle (PDLC) will fix issues with missing delivery dates:

    Too often CTOs see repeated problems in their development life cycles, such as missing release dates, and wrongly blame the development methodology. Make sure you’re fixing the right thing — lack of ownership or involvement in and/or incomplete understanding of the current PDLC are among the most common root causes of late dates.

    4) Allowing history to repeat itself:

    Organizations don’t spend enough time looking at past failures. The best and easiest way to improve your future performance is to track your past failures, group them by causation and treat the root cause rather than the symptoms. Keep incident logs and review them monthly to identify recurring problems.

    5) Scaling through third parties:

    If you’re a hyper-growth SaaS site, you don’t want to be locked into a vendor for your future business viability; rather you want to make sure that the scalability of your site is a core competency and that it’s built into your architecture. Define how your platform scales through your efforts, not through the systems that a third-party vendor provides.

    6) Relying on QA to find your mistakes:

    You cannot test quality into a system and it’s mathematically impossible to test all possibilities within complex systems to guarantee the correctness of a platform or feature. QA is a risk mitigation function and it should be treated as such. Defects are an engineering problem, and that’s where the problem should be treated.

    7) Relying on “revolutionary” or “big bang” fixes:

    The degree of success of complete rewrites or re-architecture efforts typically ranges somewhere between not returning the expected ROI and complete failure. The best projects — and the ones with the greatest returns — are not revolutionary but evolutionary. Go ahead and paint that vivid description of the ideal future, but approach it as a series of small steps.

    8) Not taking into account the multiplicative effect of failure:

    Every time you have one service call another service in a synchronous fashion, you are lowering your theoretical availability. If each of your services is designed to be 99.999 percent available, then the product of all of the service calls is your theoretical availability. Five calls is (.99999)^5 or 99.995 availability. Eliminate synchronous calls wherever possible and create fault-isolative architectures to help you identify problems quickly.

    9) Failing to create and incent a culture of excellence:

    Bring in the right people and hold them to high standards. You will never know what your team can do unless you find out how far they can go. Set aggressive yet achievable goals and motivate them with your vision. Be a leader.

    10) Not having a business continuity/disaster recovery plan:

    No one expects a disaster, but they happen, and if you can’t maintain normal business operations you will lose both revenue and customers. A solid business continuity plan explains to everyone how to operate in the event of an emergency. Even worse is not having a disaster recovery plan, which outlines how you will restore your site in the event a disaster shuts down a critical piece of your infrastructure, such as your collocation facility or connectivity provider. Our preference is to provide your own disaster recovery through multiple collocation facilities.

    0

    Add a comment

  4. What's New in MSDN Code Gallery?
    0

    Add a comment

Subscribe
Subscribe
Favorite Links
Blog Archive
About Me
Loading
Dynamic Views theme. Powered by Blogger. Report Abuse.