Wednesday, February 17, 2010

MVC Overview, Agile, Methodology, ADO.NET Entity Framework

ASP.NET MVC Overview (C#)

The Model-View-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 MVC-based 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 namespace and is a fundamental, supported part of the System.Web namespace.

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 SQL Server.

In small applications, the model is often a conceptual separation instead of a physical one. For example, if the application only reads a data set and sends it to the view, the application does not have a physical model layer and associated classes. In that case, the data set 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 Products 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 queries the database by using the values.

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.

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.

The loose coupling between the three main components of an MVC application also promotes parallel development. For instance, 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.

Deciding 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.)

Advantages of an MVC-Based Web Application

·         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 on the MSDN Web site.

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

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

Advantages of a Web Forms-Based Web Application

·         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 on the MSDN Web site.

·         It uses view state or 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

·         Separation of application tasks (input logic, business logic, and UI logic), testability, and test-driven development (TDD) by default. 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 allows 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.

·         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.


Many of us have experienced projects that drag on much longer than expected and cost more than planned. Companies looking to improve their software development processes are now exploring how Agile can help their Enterprise more reliably deliver software quickly, iteratively and with a feature set that hits that mark.  While Agile has different "flavors", Scrum is one process for implementing Agile.  This newsletter is the first in a series of newsletters that will discuss the Agile Scrum process and will end with variants of Scrum that can be used to aid in improving your software releases.

So what is Agile?
According to Wikipedia, Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.   Simply put, Agile allows your team to identify the most critical features of the software that can be completed within a short time frame (normally 1 to 2 months), and it delivers a complete build with this set of limited features as the first iteration. Once that is done, you can move those features to production or continue on to the next iteration.  By breaking the releases into shorter stints, it allows you to gain quicker releases and to capture return on investment more quickly by putting the working (but limited) features into production sooner.  This is in stark contrast to the more traditional "Waterfall" approach, where you design all features upfront, code each one, test each one, then move into production.  Agile projects are iteratively released to production months where Waterfall projects normally span a year or more before they are released to production.

So what is Scrum?
Scrum is process of implementing Agile, where features are delivered in 30 day sprints.  Scrum borrows its name from Rugby,  where a sprint is the process of stopping play, then vigorously playing until the sprint ends and a new one begins.  The same idea applies here, where you define the requirements for a 30 day sprint and work on them with vigor for 30 days without being sidetracked by other things or having things re-prioritized.   A specific feature is not recognized as being completed until it is analyzed, designed, coded, tested, re-factored and documented.  At the end of the 30 day sprint, most features defined in the 30-day sprint should be completed.  If some did not get finished (because of being underestimated), the uncompleted features can be moved to a later sprint.  A sprint is considered successful if all the completed features have high quality and can be put into production (or beta) upon ending the sprint. 

Do Team Member Responsibilities Change?
Managing Scrum development requires a major change in how teams work together.  In traditional Waterfall development, teams normally have a project sponsor, a project manager, analysts, designers, programmers, testers, and documentation specialists.  Each team member has specific duties which normally do not overlap and they have a specific reporting structure (most team members report to the project manager).

With Scrum, you have just 3 team roles and they are normally limited to 7 or less individuals (however, you can have multiple Scrum teams in sets of 7 or less):

  • Product Owner - This is the person that identifies and prioritizes the features that will appear in a 30 day sprint.  This is normally the CEO, CTO, or some other high level stakeholder that ultimately is responsible for shaping the roadmap of their product.
  • ScrumMaster - The ScrumMaster is akin to the Project Manager in Waterfall environments, but does not manage the team deliverables at a micro level.  Instead, this person is responsible for ensuring that the 30 day sprint stays on course, no new features are added to the sprint, code inspection, and ensuring everyone plays by the rules.
  • The Team - With Waterfall, a team consists of analysts, designers, testers and documentation specialists.  With Scrum, each team member is empowered and expected to self-manage themselves and to participate in all duties needed to deliver a feature.  This includes analysis, design, coding, testing and documentation.

So how does Scrum Work on a Day-by-Day Basis?
Scrum begins with an 8 hour Scrum Kickoff Meeting.  The Scrum Kickoff meeting is divided into (2) 4 hour segments, where you first determine what features are desired for the 30 day sprint.  The last 4 hours are used to provide rough estimates for the items identified for the sprint.  If the estimates exceed the available resources, the features are prioritized and less important features are dropped from the sprint.  An important component of Scrum is using a time-box approach, where meetings and events have a definite time period (e.g. no more than 8 hours for the kickoff meeting) and this time-box is strictly enforced.  Once the features are locked in for the 30-day sprint, no changes are allowed (new features can not be introduced until the next sprint).  When estimating features for a sprint, the estimates must include time for analysis, design, coding, testing, re-factoring, and documentation.  A feature is not considered complete until all those things are done.

Each day, a Daily Scrum Meeting is held to determine how the features are progressing.  The meeting is no longer than 15 minutes, and each team member is asked 3 questions:

  • What have you accomplished since the last Daily Scrum Meeting?
  • What will you do before the next Daily Scrum Meeting?
  • Is there anything that is impeding your progress (and remedies are discussed)?

From a programmer's perspective, Scrum development is a new paradigm which is very empowering but does require them to follow specific rules:

  • Code is only checked out for the duration needed to complete a feature.  No exceptions.  Most code will be checked in daily, as most features are broken down into small feature sets.
  • Time must be entered daily.   For each feature, you will have estimated hours, actual hours and hours remaining to complete the feature.  This information must be updated at the end of every day so that the ScrumMaster can determine if the release progress is trending as required.
  • Programmers are not allowed to be pulled off on tangent projects, they must stick to the features they have been assigned for the sprint.
  • All team members must attend the Daily Scrum Meeting and must be on time.
  • Code is compiled and deployed to a test server daily. Teams can use automated build tools to speed up this process.  Automated tests should be run against the daily releases to discover any issues introduced by the release.

Once a Scrum 30 day sprint is completed, all features that were completed can then be moved to a beta or production environment.  Following the sprint is a Retrospective (post mortem), where team members discuss and document things that went well and things that can be improved upon in the next sprint.


1. organizing system: the methods or organizing principles underlying a particular art, science, or other area of study 2. study of organizing principles: in philosophy, the study of organizing principles and underlying rules 3. study of research methods: the study of methods of research

"the analysis of the principles of methods, rules, and postulates employed by a discipline";"the systematic study of methods that are, can be, or have been applied within a discipline".

ADO.NET Entity Framework

The ADO.NET Entity Framework is designed to enable developers to create data access applications by programming against a conceptual application model instead of programming directly against a relational storage schema. The goal is to decrease the amount of code and maintenance required for data-oriented applications. Entity Framework applications provide the following benefits:

1.  Applications can work in terms of a more application-centric conceptual model, including types with inheritance, complex members, and relationships.

2. Applications are freed from hard-coded dependencies on a particular data engine or storage schema.

3. Mappings between the conceptual model and the storage-specific schema can change without changing the application code.

4. Developers can work with a consistent application object model that can be mapped to various storage schemas, possibly implemented in different database management systems.

5. Multiple conceptual models can be mapped to a single storage schema.

6. Language-integrated query (LINQ) support provides compile-time syntax validation for queries against a conceptual model.

Windows Communication Foundation (WCF) is an SDK for developing and deploying services on Windows. WCF provides a runtime environment for your services, enabling you to expose CLR types as services, and to consume other services as CLR types. Although in theory you could build services without WCF, in practice building services is significantly easier with WCF. WCF is Microsoft's implementation of a set of industry standards defining service interactions, type conversion, marshaling, and various protocols' management. Because of that, WCF provides interoperability between services. WCF provides developers with the essential off-the-shelf plumbing required by almost any application, and as such, it greatly increases productivity. The first release of WCF provides many useful facilities for developing services, such as hosting, service instance management, asynchronous calls, reliability, transaction management, disconnected queued calls, and security. WCF also has an elegant extensibility model that you can use to enrich the basic offering. In fact, WCF itself is written using this extensibility model. The rest of the chapters in this book are dedicated to those aspects and features. Most all of the WCF functionality is included in a single assembly called System.ServiceModel.dll in the System.ServiceModel namespace.


  1. This comment has been removed by the author.

  2. I like your post Jatin...keep posting similar!!