Can we overload on return types

What is a Delegate?

What is a Delegate?
delegates are function pointers that point to function of matching signatures.

On the other hand .NET framework has introduced a type-safe mechanism called delegates, with automatic verification of the signature by the compiler.

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

Delegates are of two types:

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.

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.

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.

How to Detect an Error in T-SQL

After each statement in T-SQL, SQL Server sets the global variable @@error to 0, unless an error occurs, in which case @@error is set to the number of that error.

More precisely, if SQL Server emits a message with a severity of 11 or higher,
@@error will hold the number of that message.
And if SQL Server emits a message with a severity level of 10 or lower,
SQL Server does not set @@error,
and thus you cannot tell from T-SQL that the message was produced.


There is no way to prevent SQL Server from raising error messages.
There is a small set of conditions for which you can use SET commands to control whether these conditions are errors or not

@@error is set after each statement.

Example

CREATE TABLE notnull(a int NOT NULL)
DECLARE @err int,
       @value int
INSERT notnull VALUES (@value)
SELECT @err = @@error
IF @err <> 0
  PRINT '@err is ' + ltrim(str(@err)) + '.'

The output is:

Server: Msg 515, Level 16, State 2, Line 3
Cannot insert the value NULL into column 'a', table
'tempdb.dbo.notnull'; column does not allow nulls. INSERT fails.
The statement has been terminated.
@err is 515.

How can we take decision about when we have to use Interface and when Abstract Class

How can we take decision about when to use Interface and when Abstract Class.

When we thinking about the entity there are two things one is intention and one is implemntation.

I am trying to make a Content Management System where content is a genralize form of article, reviews, blogs etc.

CONTENT

ARTICLE

BLOGS

REVIEW

So content is our base class now how we make a decision whether content class should be Abstract class, Interface or normal class.

First normal class vs other type (abstract and interface).

If content is not a core entity of my application means as per the business logic if content is nothing in my application only Article, Blogs, Review are the core part of business logic then content class should not be a normal class because I’ll never make instance of that class.

So if you will never make instance of base class then Abstract class and Interface are the more appropriate choice.

Second between Interface and Abstract Class.

CONTENT Publish ()

ARTICLE

BLOGS

REVIEW

As you can see content having behavior named “Publish”. If according to my business logic Publish having some default behavior which apply to all I’ll prefer content class as an Abstract class.

If there is no default behavior for the “Publish” and every drive class makes their own implementation then there is no need to implement “Publish” behavior in the base case I’ll prefer Interface.

These are the in general idea of taking decision between abstract class, interface and normal class. But there is one catch.

As we all know there is one constant in software that is “CHANGE”.

If I made content class as Interface then it is difficult to make changes in base class because if I add new method or property in content interface then I have to implement new method in every drive class.

These problems will over come if you are using abstract class for content class and new method is not an abstract type.

So we can replace interface with abstract class except multiple inheritance.

CAN-DO and IS-A relationship is also define the deference between Interface and abstract class.

Interface can be use for multiple inheritance

for example we have another interface named “ICopy” which having behavior copy and every drive class have to implements its own implementation of Copy.

If “Article” class drive from abstract class Content as well as ICopy then article “CAN-DO” copy also.

IS-A is for “generalization” and “specialization” means content is a generalize form of Article, Blogs, Review and Article, Blogs, Review are a specialize form of Content.

So, abstract class defines core identity.

If we are thinking in term of speed then

abstract is fast than interface because interface requires extra in-direction.

Abstract Class vs Interface -1

Abstract Class vs Interface

We can not make instance of Abstract Class as well as Interface.

Here are few differences in Abstract class and Interface as per the definition.

Abstract class can contain abstract methods, abstract property as well as other members (just like normal class).

Interface can only contain abstract methods, properties but we don’t need to put abstract and public keyword. All the methods and properties defined in Interface are by default public and abstract.

//Abstarct Class

public abstract class Vehicles

{

private int noOfWheel;

private string color;

public abstract string Engine

{

get;

set;

}

public abstract void Accelerator();

}

//Interface

public interface Vehicles

{

string Engine

{

get;

set;

}

void Accelerator();

}

abstract class contains private members,

we can put some methods with implementation also.

But in case of interface only methods and properties allowed.

We use abstract class and Interface for the base class in our application.

Transaction-,SQL Transaction

What Is Transaction And Type Of Transaction In SQL

A transaction in SQL is a larger unit of database processing that contains one or more database access operations like insertion ,deletion, retrieval and modification operations.

These transaction are required to fulfil certain characteristics and they are :

ACID Property

Atomicity: The transaction is either performed entirely or not performed at all.

Isolation: The transaction should not be interfered by any other transaction executing concurrently.
Durability: The changes made by the transaction should be permanently committed in the database.
Consistency : If the database was consistent before the execution of the transaction .It should remain consistent after the complete execution of that transaction.

There are two types of transactions: explicit and implicit

Explicit are those that need to be specified like : commit and roll-back

Commit transaction signals that the transaction was successfully executed and the changes/ updates (if any) made by the transaction have been committed to the database and these changes cannot be undone.

Roll-back signals that the transaction was not successfully executed , and the changes/updates made by the transaction have to be undone.

Implicit transactions are those that mark beginning and end of the transaction, each statement like update, delete , insert run within these implicit transactions.,However, you can explicitly specify the beginning and ending of the transaction by "begin transaction" and "end transaction" statements respectively. All the statements within these two boundaries will be marked as one transaction.

Design Patterns-Singleton Pattern

Singleton Pattern

The intent of the Singleton pattern defined in Design Patterns is -
To "ensure a class has only one instance, and provide a global point of access to it".

what problem does this solve,?
what is our motivation to use it?

In nearly every application, there is a need to have an area from which to globally access and maintain some type of data. There are also cases in object-oriented (OO) systems where there should be only one class, or a predefined number of instances of a class, running at any given time. For example, when a class is being used to maintain an incremental counter, the simple counter class needs to keep track of an integer value that is being used in multiple areas of an application. The class needs to be able to increment this counter as well as return the current value. For this situation, the desired class behavior would be to have exactly one instance of a class that maintains the integer and nothing more.

Another simple example is :
You are creating Database connection class.creating its object and sharing in the project.

Logical Model

The model for a singleton is very straightforward. There is (usually) only one singleton instance. Clients access the singleton instance through one well-known access point. The client in this case is an object that needs access to a sole instance of a singleton.

Sample Singleton Usage

sealed class SingletonCounter {
public static readonly SingletonCounter Instance =
     new SingletonCounter();
private long Count = 0;
private SingletonCounter() {}
public long NextValue() {
    return ++Count;
}
}

class SingletonClient {
[STAThread]
static void Main() {
    for (int i=0; i<20;>
----------------------------------------
The Singleton design pattern is a very useful mechanism for providing a
single point of object access in an object-oriented application.
Regardless of the implementation used, the pattern provides a commonly
understood concept that can be easily shared among design and
development teams.


The .NET Framework goes a long way to help an implementer
of a pattern design the type of functionality desired without having to
deal with many of the side effects discussed in this article.

Difference between MVC and MVP patterns

Difference between MVC and MVP patterns:
In the MVP the UI frontend only interacts with the View and not with the controller. The View is therefore more than just an observer. What this means is that when a user action is received by the page in case of the MVC this is sent to the controller. In case of MVP the user action is sent by the UI page to the view which then in turn calls the presenter. See my diagram below:

Advantages of MVP over MVC

The distinct advantage that MVP has over MVC is that MVP is a better bet for UI intensive projects. MVP is also more accommodating towards mock tests. Some disadvantages of MVP include the time taken to re-factor code to fit this pattern. MVC is better suited for projects with complex navigation. MVP is more suited for winform projects than MVC. Also where applications need to support both winforms and webforms then MVP is the best bet. Because in such cases the Model and the Presenter code can be reused as is.

The MVP is now considered “retired” and is only referred to by its two variants. One a “MVP - Supervising controller” and two a “MVP - Passive View”. The distinction is based on the degree of control a presenter exercises over a view. Advantages in using a Passive View is that it is more testable via mocks. But a supervising controller is more suited than a passive model for heavy UI data that includes grids or lists. Disadvantages of both these types: inclusion of extra levels of layers of code, and a possible lack of awareness of the presenter of changes to the model.


Advantages of MVC over MVP

So where does MVC score over the MVP? MVC takes lesser development time than an MVP. This also takes lesser testing effort than the MVP and suffices for most small medium projects. Also the key to any good design is good controller. So for most projects MVC would suffice.

source: consultingblogs.emc.com

Comparing the MVC Framework to Classic ASP.NET

The ASP.NET MVC Framework is essentially the Microsoft's attempt to create an ASP.NET programming environment centered around the MVC pattern. For the time being (nobody can reasonably foresee future evolutions), the MVC Framework should be considered an alternative to Web Forms. To some extent, the MVC Framework and Web Forms have in common more or less what cars and motorcycles share. Both can take you somewhere else, but with different speed, comfort, sense of freedom, size of the trunk.

The MVC Framework doesn't support classic postbacks and viewstate and doesn't consider any URL as the endpoint to a physical server file to parse and compile to a class. In ASP.NET, you have a 1:1 correspondence between a URL and a resource. The only exception to this rule is when you use completely custom HTTP handlers bound to a particular path.

In the MVC Framework, a URL is seen as the mean to address a logical server resource, but not necessarily an ASPX file to parse. So the URLs employed by the pages of an MVC Framework application have a custom format that the application itself mandates. In the end, the MVC Framework employs a centralized HTTP handler that recognizes an application-specific syntax for links. In addition, each addressable resource exposes a well-known set of operations and a uniform interface for executing operations.

Have you ever heard about Representational State Transfer, or REST for short?

Well, REST is an architectural pattern that defines how network resources should be defined and addressed in order to gain shorter response times, clear separation of concerns between the front-end and back-end of a networked system. REST is based on three following principles:

• An application expresses its state and implements its functionality by acting on logical resources
• Each resource is addressed using a specific URL syntax
• All addressable resources feature a contracted set of operations

As you can see, the MVC Framework fulfills it entirely.

So here's an alternate way of looking at the MVC Framework. It is an ASP.NET framework that performs data exchange by using a REST model versus the postback model of classic ASP.NET. Each page is split into two distinct components -controller and view - that operate over the same model of data. This is opposed to the classic code-behind model where no barrier is set that forces you to think in terms of separation of concerns and controllers and views. However, by keeping the code-behind class as thin as possible, and designing the business layer appropriately, a good developer could achieve separation of concerns even without adopting MVC and its overhead. MVC, however, is a model superior to a properly-done code-behind for its inherent support for test-driven development.

The figure below summarizes my perspective of classic ASP.NET and the MVC Framework.

Contrasting ASP.NET and the MVC Framework

While MVC is definitely a key part of the framework, I wouldn't consider it is the most compelling part. REST is a possible alternative to the postback model, whereas MVC is an alternative to code-behind.

source :www.dotnetslackers.com

ASP.NET MVC

ASP.NET MVC is a part of the ASP.NET Web application framework. It is one of the two different programming models you can use to create ASP.NET Web applications,the other being ASP.NET Web Forms.

An MVC Application is designed and implemented using the following three attributes

• Model: The model contains the core information for an application. This includes the data and validation rules as well as data access and aggregation logic.
• View: The view encapsulates the presentation of the application, and in ASP.NET this is typically the HTML markup.
• Controller: The controller contains the control-flow logic. It interacts with the Model and Views to control the flow of information and execution of the application.

This separation of entity allows you to have nimbleness and flexibility in building and maintaining your application. For example, by separating the views, you can iterate on the appearance of your application without touching on any of the core business logic. You can also separate work by role, so that, for example designers can work on the views, while developers work on the model.

ASP.NET MVC brings the power of this development paradigm to ASP.NET development, allowing you to use your .NET development skills to build MVC applications.

It gives you

• Complete control over your HTML Markup
• Enables rich AJAX and jQuery integration
• Allows you to create SEO-friendly URLs for your site
• Makes Test Driven Development (TDD) easy

sourcce-www.asp.net