What is an Assembly...

In the .NET framework, an assembly is a compiled code library used for deployment, versioning, and security.

There are two types:

1.process assemblies (EXE) and

2.library assemblies (DLL).

A process assembly represents a process which will use classes defined in library assemblies. .NET assemblies contain code in CIL, which is usually generated from a CLI language, and then compiled into machine language at run time by the CLR just-in-time compiler.

An assembly can consist of one or more files. Code files are called modules. An assembly can contain more than one code module and since it is possible to use different languages to create code modules it is technically possible to use several different languages to create an assembly. Visual Studio however does not support using different languages in one assembly.

http://en.wikipedia.org/wiki/.NET_assembly

An assembly is a file that is automatically generated by the compiler upon successful compilation of every .NET application.

It can be either a Dynamic Link Library or an executable file.

It is generated only once for an application and upon each subsequent compilation the assembly gets updated.

The entire process will run in the background of your application; there is no need for you to learn deeply about assemblies. However, a basic knowledge about this topic will help you to understand the architecture behind a .NET application.

The assembly also contains metadata that is known as assembly manifest.

The assembly manifest contains data about the versioning requirements of the assembly, like author name of the assembly, the security requirements to run and the various files that form part of the assembly.

When you compile your source code by default the exe/dll generated is actually an assembly.

More accurately, an assembly is the primary unit of deployment, security, and version control in the .NET Framework.

Advantages of Assemblies:-

1. ASP.Net assemblies has a lot of good advantages when compare to conventional DLLs that the developers use to develop earlier. In the case of DLLs if a DLL has to be shared with some other application, it has to be registered in that particular machine. But, In the case of Asp.net assemblies there is no such type of registration required. Here we just need to do is to copy the assembly and put in the bin directory of the application that is going to use it.
2. If we need to share a particular assembly with any other applications., we can do so by placing the assembly in the Global Assembly Cache (GAC). But before we going to do it we need to give a strong name to that assembly.Strong name is similar to GUID(It is supposed to be unique in space and time) in COM, components.Strong Name is only needed when we need to deploy assembly in Global Assembly Cache (GAC).Strong Names helps GAC to differentiate between two versions.Strong names use public key cryptography (PKC) to ensure that no one can spoof it.PKC use public key and private key concept.
3. Another advantage of using ASP.Net assemblies is the ability to read the contents of an assembly. Each assembly has a manifest that has details about the assembly itself.
4. The System.Reflection namespace has classes like Assembly which can be used to get the details of the assembly and with that it is also possible to load an assembly dynamically at runtime.

Go through the below link for detailed information about assemblies:

http://msdn.microsoft.com/en-us/library/hk5f40ct%28v=vs.71%29.aspx


--

ASP.NET MVC Overview

Controller (MVC) architectural pattern separates an application into three main components: the model, the view, and the controller. The ASP.NET MVC framework provides an alternative to the ASP.NET Web Forms pattern for creating Web applications. The ASP.NET MVC framework is a lightweight, highly testable presentation framework that (as with Web Forms-based applications) is integrated with existing ASP.NET features, such as master pages and membership-based authentication. The MVC framework is defined in the System.Web.Mvc assembly.

MVC design pattern

MVC is a standard design pattern that many developers are familiar with. Some types of Web applications will benefit from the MVC framework. Others will continue to use the traditional ASP.NET application pattern that is based on Web Forms and postbacks. Other types of Web applications will combine the two approaches; neither approach excludes the other.

The MVC framework includes the following components:

• Models. Model objects are the parts of the application that implement the logic for the application's data domain. Often, model objects retrieve and store model state in a database. For example, a Product object might retrieve information from a database, operate on it, and then write updated information back to a Products table in a SQL Server database.

  In small applications, the model is often a conceptual separation instead of a physical one. For example, if the application only reads a dataset and sends it to the view, the application does not have a physical model layer and associated classes. In that case, the dataset takes on the role of a model object.

• Views. Views are the components that display the application's user interface (UI). Typically, this UI is created from the model data. An example would be an edit view of a Products table that displays text boxes, drop-down lists, and check boxes based on the current state of a Product object.

• Controllers. Controllers are the components that handle user interaction, work with the model, and ultimately select a view to render that displays UI. In an MVC application, the view only displays information; the controller handles and responds to user input and interaction. For example, the controller handles query-string values, and passes these values to the model, which in turn might use these values to query the database.

The MVC pattern helps you create applications that separate the different aspects of the application (input logic, business logic, and UI logic), while providing a loose coupling between these elements. The pattern specifies where each kind of logic should be located in the application. The UI logic belongs in the view. Input logic belongs in the controller. Business logic belongs in the model. This separation helps you manage complexity when you build an application, because it enables you to focus on one aspect of the implementation at a time. For example, you can focus on the view without depending on the business logic.

The loose coupling between the three main components of an MVC application also promotes parallel development. For example, one developer can work on the view, a second developer can work on the controller logic, and a third developer can focus on the business logic in the model.

Support for Test-Driven Development

In addition to managing complexity, the MVC pattern makes it easier to test applications than it is to test a Web Forms-based ASP.NET Web application. For example, in a Web Forms-based ASP.NET Web application, a single class is used both to display output and to respond to user input. Writing automated tests for Web Forms-based ASP.NET applications can be complex, because to test an individual page, you must instantiate the page class, all its child controls, and additional dependent classes in the application. Because so many classes are instantiated to run the page, it can be hard to write tests that focus exclusively on individual parts of the application. Tests for Web Forms-based ASP.NET applications can therefore be more difficult to implement than tests in an MVC application. Moreover, tests in a Web Forms-based ASP.NET application require a Web server. The MVC framework decouples the components and makes heavy use of interfaces, which makes it possible to test individual components in isolation from the rest of the framework.

When to Create an MVC Application

You must consider carefully whether to implement a Web application by using either the ASP.NET MVC framework or the ASP.NET Web Forms model. The MVC framework does not replace the Web Forms model; you can use either framework for Web applications. (If you have existing Web Forms-based applications, these continue to work exactly as they always have.)

Before you decide to use the MVC framework or the Web Forms model for a specific Web site, weigh the advantages of each approach.

Advantages of an MVC-Based Web Application

The ASP.NET MVC framework offers the following advantages:

• It makes it easier to manage complexity by dividing an application into the model, the view, and the controller.

• It does not use view state or server-based forms. This makes the MVC framework ideal for developers who want full control over the behavior of an application.

• It uses a Front Controller pattern that processes Web application requests through a single controller. This enables you to design an application that supports a rich routing infrastructure. For more information, see Front Controller.

• It provides better support for test-driven development (TDD).

• It works well for Web applications that are supported by large teams of developers and for Web designers who need a high degree of control over the application behavior.

Advantages of a Web Forms-Based Web Application

The Web Forms-based framework offers the following advantages:

• It supports an event model that preserves state over HTTP, which benefits line-of-business Web application development. The Web Forms-based application provides dozens of events that are supported in hundreds of server controls.

• It uses a Page Controller pattern that adds functionality to individual pages. For more information, see Page Controller.

• It uses view state on server-based forms, which can make managing state information easier.

• It works well for small teams of Web developers and designers who want to take advantage of the large number of components available for rapid application development.

• In general, it is less complex for application development, because the components (the Page class, controls, and so on) are tightly integrated and usually require less code than the MVC model.

Features of the ASP.NET MVC Framework

The ASP.NET MVC framework provides the following features:

• Separation of application tasks (input logic, business logic, and UI logic), testability, and test-driven development (TDD). All core contracts in the MVC framework are interface-based and can be tested by using mock objects, which are simulated objects that imitate the behavior of actual objects in the application. You can unit-test the application without having to run the controllers in an ASP.NET process, which makes unit testing fast and flexible. You can use any unit-testing framework that is compatible with the .NET Framework.

• An extensible and pluggable framework. The components of the ASP.NET MVC framework are designed so that they can be easily replaced or customized. You can plug in your own view engine, URL routing policy, action-method parameter serialization, and other components. The ASP.NET MVC framework also supports the use of Dependency Injection (DI) and Inversion of Control (IOC) container models. DI enables you to inject objects into a class, instead of relying on the class to create the object itself. IOC specifies that if an object requires another object, the first objects should get the second object from an outside source such as a configuration file. This makes testing easier.

• Extensive support for ASP.NET routing, which is a powerful URL-mapping component that lets you build applications that have comprehensible and searchable URLs. URLs do not have to include file-name extensions, and are designed to support URL naming patterns that work well for search engine optimization (SEO) and representational state transfer (REST) addressing.

• Support for using the markup in existing ASP.NET page (.aspx files), user control (.ascx files), and master page (.master files) markup files as view templates. You can use existing ASP.NET features with the ASP.NET MVC framework, such as nested master pages, in-line expressions (<%= %>), declarative server controls, templates, data-binding, localization, and so on.

• Support for existing ASP.NET features. ASP.NET MVC lets you use features such as forms authentication and Windows authentication, URL authorization, membership and roles, output and data caching, session and profile state management, health monitoring, the configuration system, and the provider architecture.

Creating a New MVC Project

To begin, you will create a new ASP.NET MVC project.

To create a new MVC project

1. On the File menu, click New Project.

   The New Project dialog box is displayed.

   

2. In the upper-right corner, make sure that .NET Framework 3.5 is selected.

3. Under Project types, expand either Visual Basic or Visual C#, and then click Web.

4. Under Visual Studio installed templates, select ASP.NET MVC 2 Web Application.

5. In the Name box, enter MvcBasicWalkthrough.

6. In the Location box, enter a name for the project folder.

7. If you want the name of the solution to differ from the project name, enter a name in the Solution Name box.

8. Select Create directory for solution.

9. Click OK.

   The Create Unit Test Project dialog box is displayed.

   
   

10. Select Yes, create a unit test project.

    By default, the name of the test project is the application project name with "Tests" added. However, you can change the name of the test project. By default, the test project will use the Visual Studio Unit Test framework. For information about how to use a third-party test framework, see How to: Add a Custom ASP.NET MVC Test Framework in Visual Studio.

11. Click OK.

    The new MVC application project and a test project are generated. (If you are using the Standard or Express editions of Visual Studio, the test project is not created.)

Examining the MVC Project

---

The following illustration shows the folder structure of a newly created MVC solution.

The folder structure of an MVC project differs from that of an ASP.NET Web site project. The MVC project contains the following folders:

• Content, which is for content support files. This folder contains the cascading style sheet (.css file) for the application.

• Controllers, which is for controller files. This folder contains the application's sample controllers, which are named AccountController and HomeController. The AccountController class contains login logic for the application. The HomeController class contains logic that is called by default when the application starts.

• Models, which is for data-model files such as LINQ-to-SQL .dbml files or data-entity files.

• Scripts, which is for script files, such as those that support ASP.NET AJAX and jQuery.

• Views, which is for view page files. This folder contains three subfolders: Account, Home, and Shared. The Account folder contains views that are used as UI for logging in and changing passwords. The Home folder contains an Index view (the default starting page for the application) and an About page view. The Shared folder contains the master-page view for the application.

If you are using an edition of Visual Studio other than Standard or Express, a test project was also generated. The test project has a Controllers folder that contains the HomeControllerTest class. This class has a unit test for each HomeController action method (Index and About).

The newly generated MVC project is a complete application that you can compile and run without change. The following illustration shows what the application looks like when it runs in a browser.

The unit-test project is also ready to compile and run. For this walkthrough, you will add a controller with an action method and a view, and you will add a unit test for the action method.

Follow the link for more details:

http://msdn.microsoft.com/en-us/library/dd410597.aspx

Follow the link for the book containing the MVC Music Store Example which is very useful

https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B9TnMbt-PylYMGQ2NjY3ZTEtM2UxNy00OWZlLTk2OWYtNjljOWJhMjU2ODBh&hl=en_US

Differences between Interfaces and Abstract Classes

Introduction

In this article along with the demo project I will discuss Interfaces versus Abstract classes. The concept of Abstract classes and Interfaces is a bit confusing for beginners of Object Oriented programming. Therefore, I am trying to discuss the theoretical aspects of both the concepts and compare their usage. And finally I will demonstrate how to use them with C#.

Background

An Abstract class without any implementation just looks like an Interface; however there are lot of differences than similarities between an Abstract class and an Interface. Let's explain both concepts and compare their similarities and differences.

What is an Abstract Class?

An abstract class is a special kind of class that cannot be instantiated. So the question is why we need a class that cannot be instantiated? An abstract class is only to be sub-classed (inherited from). In other words, it only allows other classes to inherit from it but cannot be instantiated. The advantage is that it enforces certain hierarchies for all the subclasses. In simple words, it is a kind of contract that forces all the subclasses to carry on the same hierarchies or standards.

What is an Interface?

An interface is not a class. It is an entity that is defined by the word Interface. An interface has no implementation; it only has the signature or in other words, just the definition of the methods without the body. As one of the similarities to Abstract class, it is a contract that is used to define hierarchies for all subclasses or it defines specific set of methods and their arguments. The main difference between them is that a class can implement more than one interface but can only inherit from one abstract class. Since C# doesn't support multiple inheritance, interfaces are used to implement multiple inheritance.

Both Together

When we create an interface, we are basically creating a set of methods without any implementation that must be overridden by the implemented classes. The advantage is that it provides a way for a class to be a part of two classes: one from inheritance hierarchy and one from the interface.
When we create an abstract class, we are creating a base class that might have one or more completed methods but at least one or more methods are left uncompleted and declared abstract. If all the methods of an abstract class are uncompleted then it is same as an interface. The purpose of an abstract class is to provide a base class definition for how a set of derived classes will work and then allow the programmers to fill the implementation in the derived classes.

There are some similarities and differences between an interface and an abstract class that I have arranged in a table for easier comparison:

Feature	Interface	Abstract class
Multiple inheritance	A class may inherit several interfaces.	A class may inherit only one abstract class.
Default implementation	An interface cannot provide any code, just the signature.	An abstract class can provide complete, default code and/or just the details that have to be overridden.
Access Modifiers	An interface cannot have access modifiers for the subs, functions, properties etc everything is assumed as public	An abstract class can contain access modifiers for the subs, functions, properties
Core VS Peripheral	Interfaces are used to define the peripheral abilities of a class. In other words both Human and Vehicle can inherit from an IMovable interface.	An abstract class defines the core identity of a class and there it is used for objects of the same type.
Homogeneity	If various implementations only share method signatures then it is better to use Interfaces.	If various implementations are of the same kind and use common behavior or status then abstract class is better to use.
Speed	Requires more time to find the actual method in the corresponding classes.	Fast
Adding functionality (Versioning)	If we add a new method to an Interface then we have to track down all the implementations of the interface and define implementation for the new method.	If we add a new method to an abstract class then we have the option of providing default implementation and therefore all the existing code might work properly.
Fields and Constants	No fields can be defined in interfaces	An abstract class can have fields and constants defined

Using the Code

Let me explain the code to make it a bit easier. There is an Employee abstract class and an IEmployee interface. Within the Abstract class and the Interface entity I am commenting on the differences between the artifacts.

I am testing both the Abstract class and the Interface by implementing objects from them. From the Employeeabstract class, we have inherited one object: Emp_Fulltime. Similarly from IEmployee we have inherited one object: Emp_Fulltime2.

In the test code under the GUI, I am creating instances of both Emp_Fulltime and Emp_Fulltime2 and then setting their attributes and finally calling the calculateWage method of the objects.

Abstract Class Employee

using System;

namespace AbstractsANDInterfaces
{
    /// 


    /// Summary description for Employee.

    /// 

    
    public abstract class Employee
    {
        //we can have fields and properties 


        //in the Abstract class

        protected String id;
        protected String lname;
        protected String fname;

        //properties


        public abstract String ID
        {
            get;
            set;
        }

        public abstract String FirstName
        {
            get;
            set;
        }
        
        public abstract String LastName
        {
            get;
            set;
        }
        //completed methods


        public String Update()
        {
            return "Employee " + id + " " + 
                      lname + " " + fname + 
                      " updated";
        }
        //completed methods


        public String Add()
        {
            return "Employee " + id + " " + 
                      lname + " " + fname + 
                      " added";
        }
        //completed methods


        public String Delete()
        {
            return "Employee " + id + " " + 
                      lname + " " + fname + 
                      " deleted";
        }
        //completed methods


        public String Search()
        {
            return "Employee " + id + " " + 
                      lname + " " + fname + 
                      " found";
        }

        //abstract method that is different 


        //from Fulltime and Contractor

        //therefore i keep it uncompleted and 

        //let each implementation 

        //complete it the way they calculate the wage.


        public abstract String CalculateWage();
        
    }
}

Interface Employee

using System;


namespace AbstractsANDInterfaces
{
    /// <summary>


    /// Summary description for IEmployee.

    /// </summary>

    public interface IEmployee
    {
        //cannot have fields. uncommenting 


        //will raise error!
        //        protected String id;
        //        protected String lname;
        //        protected String fname;


        //just signature of the properties 

        //and methods.

        //setting a rule or contract to be 

        //followed by implementations.


        String ID
        {
            get;
            set;
        }

        String FirstName
        {
            get;
            set;
        }
        
        String LastName
        {
            get;
            set;
        }
        
        // cannot have implementation


        // cannot have modifiers public 

        // etc all are assumed public

        // cannot have virtual


        String Update();

        String Add();

        String Delete();

        String Search();

        String CalculateWage();
    }
}

Inherited Objects

Emp_Fulltime:

using System;

namespace AbstractsANDInterfaces
{
    /// 


    /// Summary description for Emp_Fulltime.

    /// 

     
    //Inheriting from the Abstract class

    public class Emp_Fulltime : Employee
    {
        //uses all the properties of the 


        //Abstract class therefore no 

        //properties or fields here!


        public Emp_Fulltime()
        {
        }


        public override String ID
        {
            get

            {
                return id;
            }
            set
            {
                id = value;
            }
        }
        
        public override String FirstName
        {
            get

            {
                return fname;
            }
            set
            {
                fname = value;
            }
        }

        public override String LastName
        {
            get

            {
                return lname;
            }
            set
            {
                lname = value;
            }
        }

        //common methods that are 

        //implemented in the abstract class

        public new String Add()
        {
            return base.Add();
        }
        //common methods that are implemented 


        //in the abstract class

        public new String Delete()
        {
            return base.Delete();
        }
        //common methods that are implemented 


        //in the abstract class

        public new String Search()
        {
            return base.Search();
        }
        //common methods that are implemented 


        //in the abstract class

        public new String Update()
        {
            return base.Update();
        }
        
        //abstract method that is different 


        //from Fulltime and Contractor

        //therefore I override it here.

        public override String CalculateWage()
        {
            return "Full time employee " + 
                  base.fname + " is calculated " + 
                  "using the Abstract class...";
        }
    }
}

Emp_Fulltime2:

using System;

namespace AbstractsANDInterfaces
{
    /// 

    /// Summary description for Emp_fulltime2.


    /// 

    
    //Implementing the interface

    public class Emp_fulltime2 : IEmployee
    {
        //All the properties and 


        //fields are defined here!

        protected String id;
        protected String lname;
        protected String fname;

        public Emp_fulltime2()
        {
            //


            // TODO: Add constructor logic here

            //

        }

        public String ID
        {
            get

            {
                return id;
            }
            set
            {
                id = value;
            }
        }
        
        public String FirstName
        {
            get
            {
                return fname;
            }
            set

            {
                fname = value;
            }
        }

        public String LastName
        {
            get
            {
                return lname;
            }
            set
            {
                lname = value;
            }
        }

        //all the manipulations including Add,Delete, 


        //Search, Update, Calculate are done

        //within the object as there are not 

        //implementation in the Interface entity.

        public String Add()
        {
            return "Fulltime Employee " + 
                          fname + " added.";
        }

        public String Delete()
        {
            return "Fulltime Employee " + 
                        fname + " deleted.";
        }

        public String Search()
        {
            return "Fulltime Employee " + 
                       fname + " searched.";
        }

        public String Update()
        {
            return "Fulltime Employee " + 
                        fname + " updated.";
        }
        
        //if you change to Calculatewage(). 


        //Just small 'w' it will raise 

        //error as in interface

        //it is CalculateWage() with capital 'W'.

        public String CalculateWage()
        {
            return "Full time employee " + 
                  fname + " caluculated using " + 
                  "Interface.";
        }
    }
}