ASP.NET MVC

 

ASP.NET MVC PROJECTS

6 top level directories

1. Controllers – for controller classes that handles URL requests.
2. Models – for classes that represent and manipulate data .
3. Views – for UI Template files that are responsible for rendering output .
4. Scripts – for JavaScript(JS) library files and scripts .
5. Content – for CSS/Image files and non-dynamic/non-JS content.
6. App_Data – to store data files needed for read/write .

In a Model-View-Controller framework the term “model” refers to –:

• Objects that represent the data of the application .
• Corresponding domain logic that integrates validation and business rules with it.

LINQ to SQL
LINQ to SQL is an ORM (object relational mapper) that ships as part of .NET 3.5.
LINQ to SQL provides an easy way to map database tables to .NET classes we can code against.

This minimizes the amount of data code we need to write, and allows us to build really clean applications.

Schema Validation

When model classes are defined using the LINQ to SQL designer, the datatypes of the properties in the data model classes will correspond to the datatypes of the database table.

LINQ to SQL will also automatically handles escaping SQL values for you when using strings - so you don't need to worry about SQL injection attacks when using it.

 

 

For small applications it is sometimes fine to have Controllers work directly against a LINQ to SQL DataContext class, and embed LINQ queries within the Controllers. As applications get larger, though,
this approach becomes cumbersome to maintain and test. It can also lead to us duplicating the same LINQ queries in multiple places.

One approach that can make applications easier to maintain and test is to use a “repository” pattern.
A repository class helps encapsulate data querying and persistence logic, and abstracts away the implementation details of the data persistence from the application.

In addition to making application code cleaner, using a repository pattern can make it easier to change data storage implementations in the future, and it can help facilitate unit testing an application without requiring a real database.

Covariance and Contravariance in Delegates

Covariance and contravariance provide a degree of flexibility when matching method signatures with delegate types.

Covariance -> permits a method to have a more derived return type than what is defined in the delegate.

Contravariance -> permits a method with parameter types that are less derived than in the delegate type.

Example 1 (Covariance)
This example demonstrates how delegates can be used with methods that have return types that are derived from the return type in the delegate signature. The data type returned by SecondHandler is of type Dogs, which derives from the Mammals type that is defined in the delegate.

C#
class Mammals
{
}

class Dogs : Mammals
{
}

class Program
{
// Define the delegate.
public delegate Mammals HandlerMethod();

public static Mammals FirstHandler()
{
return null;
}

public static Dogs SecondHandler()
{
return null;
}

static void Main()
{
HandlerMethod handler1 = FirstHandler;

// Covariance allows this delegate.
HandlerMethod handler2 = SecondHandler;
}
}
Example 2 (Contravariance)
This example demonstrates how delegates can be used with methods that have parameters of a type that are base types of the delegate signature parameter type. With contravariance, you can now use one event handler in places where, previously, you would have had to use separate handlers. For example, you can now create an event handler that accepts an EventArgs input parameter and use it with the Button.MouseClick event that sends a MouseEventArgs type as a parameter, and also with TextBox.KeyDown event that sends a KeyEventArgs parameter.

C#
System.DateTime lastActivity;
public Form1()
{
InitializeComponent();

lastActivity = new System.DateTime();
this.textBox1.KeyDown += this.MultiHandler; //works with KeyEventArgs
this.button1.MouseClick += this.MultiHandler; //works with MouseEventArgs

}

// Event hander for any event with an EventArgs or
// derived class in the second parameter
private void MultiHandler(object sender, System.EventArgs e)
{
lastActivity = System.DateTime.Now;
}


Source : MSDN

SOA PRINICIPLES

Service-Oriented Architecture Principles
1)Explicit boundaries
    SOA is all about messaging—sending messages from point A to point B. These messages must be able to cross explicit and formal boundaries regardless of  what is behind those boundaries. This allows developers to keep the flexibility of how services are implemented and deployed. Explicit boundaries mean that a service can be deployed anywhere and be easily and freely accessed by other services, regardless of the     environment or development language of the other service.there is a cost associated with  crossing boundaries. These costs come in a number of forms, such as communication, performance, and processing overhead costs. Services should be called quickly and efficiently.
2)Autonomous services
    Services are built and deployed independently of other services. Systems, especially distributed systems,must evolve over time and should be built to handle change easily. This SOA principle states that each service must be managed and versioned differently so as to not affect other services in the process.
3)Policy-based compatibility
    Each service may or may not have certain requirements before it will start communicating and handing out information. Each service has its own compatibility level and knows how it will interact with other services.Services look at each others’ policy, looking for similarities so that they can start communicating. If two services can’t satisfy each others policy requirements, all bets are off. These policies exist in the form of machine-readable expressions.Policies also allow you to move a service from one environment to another without changing the behavior of the service.
4)Shared schemas(data) and contracts (behavior).
    The contract contains information regarding the structure of the message. Services do not pass classes and types;they pass schemas     and contracts. This allows for a loosely coupled system where the service does not care what type of environment the other service is executing on. The information being passed is 100 percent platform independent.

Events in C#

(Notes from HFC#)

Steps in Event execution
1)We need an event for event arguments

eg-> public class BallEventArgs : EventArgs

=> EventArgs is an empty class.It has no public members.Its sole purpose is to allow
your event arguments to be passed to the event handlers that use it .

2)Need to define the event in the class that'll raise it .

eg-> public event EventHandler BallInPlay

=>after EVENT keyword comes EVENTHANDLER.It is needed to tell object subscribing to event that
their event handlers need to take 2 parameters,an object named SENDER and an EVENTARGS reference names e,
and have no return value(void).

3)The subscribing classes need EventHandler methods

eg-> void ball_BallInPlay(object sender,EventArgs e )

=>Standard Naming Convention for EventHandlers -> NameOfObjectReference,followed by UNDERSCORE ,followed by
NameOfEvent.

4)Each individual object subscribes to the event

eg-> ball.BallInPlay += new EventHandler(ball_BallInPlay)

=>The += EVENT tells C# subscribe an event handler to an event.

5)A Ball Object raises its event to notify subscribers that it's in play

ex- if (BallInPlay !=null) BallInPlay(this,e)

Note: If you raise an event with no handlers ,it'll throw an exception.

Virtual / Overridable methods in .NET

Virtual / Overridable methods are those which may or may not implemented in the derived class,but they must have some implementation in the base class.

When a derived class method overrides its baseclass method the signature should be same as in the base class, this includes the modifier, parameters and the return type of the method, any modifications in the derived class will lead to a compilation error.

If method is declared virtual in the base class then it is not mandatory to override that function in the derived class. In fact that method need not be a part of the derived class at all. However if the method with the same signature is present in the derived class then it needs clarify whether it is overriding the base class member or not.

a)If the method in the derived class is ment to override the base class member then it needs to have the keyword 'override'

b)If the method in the derived class is not ment to override the base class member then it needs to have the keyword new [Shadows in vb.net] , this is called 'Hiding the Base Class Member'

c)If the method in the derived class has the same name as in the base class but if it has a different signature then it is not required to state either override or new since this method neither overrides not hides the base class method.


These options are not available for an Abstract method, a method declared Abstract in the Base Class must ob overridden in the derived class, it cannot hide the base class member using the 'new' keyword.

Intro to Design Patterns

Design Principle ->Identify the aspects of application that vary and seperate them from what stays the same i.e.
=>take the parts that vary and encapsulate them,so that later you can alter or extend those parts which v ary without affecting who don't.

Scrolling in DataGrid

in aspx page use "div" tag
ex:

*****div tag starting **********
id="scroll" style="height: 25em;overflow-y: auto; "> "

*******datagrid tag***********
****end of div tag*****