Tuesday, June 24, 2014

First of all, I always had trouble with JavaScript. Sometimes back I started using AngularJS and the way AngularJS implements MVC pattern kind of increased my interest towards JavaScript. Currently I am working in a Single Page Application(SPA) powered by AngularJS which communicates with the back end through ASP.NET Web API. I really am seeing the beauty of AngularJS these days.

So if you want to learn AngularJS, of course you need to know how to setup a AngularJS project in Visual Studio. There are couple of Visual Studio templates available like AngularJS SPA Template, which you can download and use with Visual Studio. But in this post, let’s see how you can create one from the scratch.

Let’s power up Visual Studio and create an Empty ASP.NET project (Please note I am using Visual Studio 2013).

ASP.NET Web Application

Empty Project

After creating the project, first let’s add AngularJS to the project using Nuget.

Adding AngularJS through Nuget

Alternatively, you can use Package Manage Console to install AngularJS. Once it gets installed, you can see a new folder named “Scripts” added to the project which contains all the AngularJS files needed to start the project off with.

Now inside my project, let’s create a folder named “App”. The “App” folder is going to be the one folder which will contain all our UI components. Inside “App” folder, let’s create two folders named “controllers” and “views”. “controllers” folder will contain all the AngularJS controllers and “views” folder will contain all the templates (html pages). All the templates will be rendered inside one html page. Let’s create that main html page named “Index.html” inside “App” folder.

Here in the “app.js”, there are some couple of key components. Since our application is Single Page Application, we don’t want any page refreshes. Here we are using AngularJS routing capabilities by injecting $routeProvider in AngularJS. There I am saying when the Url is “/” load the “views/home.html” which is bound to “homeController”. When the Url is “/about”, same way load the “views/about.html” which is bound to “aboutController”. There is also a controller defined “mainController”.

Now let’s go ahead with creating "home" and "about" views and controllers. I am adding two JavaScript files named “homeController” and “aboutController” inside “App/controllers” folder.

controllers folder

homeController.js

'use strict';

app.controller('homeController', function ($scope) {

$scope.message = "Now viewing home!";

});

aboutController.js

'use strict';

app.controller('aboutController', function ($scope) {

$scope.message = "Now viewing about!";

});

Now let’s create the views.

views folder

home.html

<div ng-controller="homeController">

<h2>{{message}}</h2>

</div>

about.html

<div ng-controller="aboutController">

<h2>{{message}}</h2>

</div>

Now let’s modify the “Index.html” integrating all together and defining which displays where.

Here first in <html>, I have mentioned ng-app directive, which powers up the AngularJS. Then in the <head></head> section, I have included all the necessary scripts. Then in <body></body> section, first I have added a <div> which will contain links for navigation. For linking to pages, # (hash tag) is used. We don’t want the browser to think we are actually travelling to “home.html” or “about.html”.

Then defined a <div> which is bound to “mainController”. There first I am displaying the value in $scope.message in “mainController”. Then I have a ng-view which defines a angular template and the templates will be injected inside ng-view.

So that’s it. When we run the project I am getting the following output.

Here note the Url is “/”

Home

Here note the Url is “/about”.

About

And when we are navigating between “Home” and “About”, there is no page refreshing.

So hope you found this interesting. I am uploading the full sample to OneDrive. Enjoy!.

Tuesday, June 17, 2014

I was working with AngularJS for like last 1 month and this is a quick post on Nested Controllers in AngularJS. In this post I am not going to write about what AngularJS is as this post is for developers who knows AngularJS.

One thing Google recommends about using a Controller is create one controller per functional area in your view. So when you do that, you will definitely be using Nested Controllers.

By creating nested controllers controllers can share model and functions through an inheritance tree. Nesting controllers is simple; you do it by simply assigning a controller to a DOM element that is inside another one, like so:

<divng-controller="ParentController">

<divng-controller="ChildController">...</div&gt

</div>

Though we express this as nested controllers, the actual nesting happens in scopes. The $scope passed to a nested controller prototypically inherits from its parent controller’s $scope. In this case, this means that the $scope passed to ChildController will have access to all the properties of the $scope passed to ParentController.

Thursday, June 12, 2014

In one of my previous posts, I wrote about OWIN and in this post I am going to write about Project Katana. To get a good understanding about Project Katana, I suggest you have some knowledge in what OWIN is.

So assuming you have some knowledge in OWIN, you should know by now that OWIN is a specification which is owned by the community and it's not owned by Microsoft. It’s not any kind of an implementation, just some list of principles defining an standard interface between .NET web servers and web applications.

So where does this Project Katana comes in. Let’s find out.

Project Katana

The Project Katana is Microsoft’s implementation of OWIN. As you know OWIN describes the whole application as a collection of four layers which are “Host”,”OWIN”,”Application Framework/Middleware” and “Application.”. In Project Katana what Microsoft has done is following the OWIN specification, they have came across many components for each of above mentioned layers. The core concept is, they are not coupled with one another.

So you might be wondering what is the reason for such decoupling.

Why

As you might already know, ASP.NET was first released in early 2002 with the release of .NET 1.0.

ASP.NET was shipped as part of the .NET Framework. Which means a newer version of ASP.NET will only be available when newer .NET Framework is released. But the issue was, the world of web was growing so fast and ASP.NET has not been able to catch up with that growth.

The another thing is everything in ASP.NET was bundled into this one assembly which is “System.Web”. Because of this tight coupling of ASP.NET with “System.Web”, the assembly got bigger and bigger as Microsoft updates or introduces features for ASP.NET.

And because of this tightly coupling, there was a major performance hit. All the options were enabled by default and users were paying money and time to process unwanted options. And most importantly because of this tightly coupling, the only hosting option was IIS.

As the first step towards change, in year 2007/2008, Microsoft shipped ASP.NET MVC separated from the .NET Framework. ASP.NET MVC was released as an independent download through Nuget and it gave the Microsoft, the flexibility to deliver updates much more frequently than had been previously possible.

In 2012, ASP.NET Web API was released. ASP.NET Web API was designed in such a manner that there is no dependencies on anything on “System.Web” and therefore, no dependencies to IIS and ASP.NET Web API included the capability to run in a custom host (for example, a console application, Windows service, etc.). By decoupling framework components from one another and then releasing them on NuGet, frameworks could now iterate more independently and more quickly.

Katana Components

If you can remember OWIN describes an ASP.NET application as a collection of four layers which are “Host”,”Server”,”Application Framework/Middleware” and “Application.”. So the Katana components for these would be as belows.

Application

ASP.NET MVC Application

Application Framework / Middleware

SignalR

ASP.NET Web API

Server

SystemWeb

HttpListener

WebListener

Host

IIS

OwinHost.exe

Custom Process

So that’s an introduction to Project Katana. Appreciate your feedback.

Tuesday, June 10, 2014

In the modern world of ASP.NET, these two : OWIN and Project Katana are among most popular topics which are being discussed among the community. So today, in this post I am going to write about the Open Web Interface for .NET(OWIN).

In simple OWIN is a not a framework, it’s not an API, it simply is a community-owned specification. I am repeating, do this keep in mind that OWIN is not an any kind of implementation. This specification is built on two core design goals.

New components could be more easily developed and consumed (Decoupling of layers).

Applications could be more easily ported between hosts and potentially entire platforms/operating systems.

By decoupling the web server from the application, OWIN makes it easier to create middleware for .NET web development. Also, OWIN makes it easier to port web applications to other hosts - for example, self-hosting in a Windows service or other process. Prior to OWIN, when you are building ASP.NET application, you are inheritably bound to IIS due to the heavy dependency on System.Web assembly. So with OWIN, does your ASP.NET application has to run on top of IIS? Not anymore, for an example you can host your ASP.NET application in a simple console application or you can run your ASP.NET application as a Windows Service.

OWIN defines a web application as a collection of four layers, the host, the server, middleware and the actual application. When running ASP.NET MVC in IIS, IIS would be the first two parts, the host and the server, the middleware would be our IHttpModules, and the application would be our MVC application.

Ok, now we know a bit about this specification called OWIN. But how does it specify things. OWIN specification is consists of two core elements.

Environment Dictionary ( IDictionary<string, object> )

Application Delegate ( Func<IDictionary<string, object>, Task> )

Environment Dictionary

The environment dictionary represents the request and server state to the application. For an example As a request comes in, it breaks it down into pieces, and adds those pieces to an IDictionary<string,object>. OWIN-compatible Web server is responsible for populating the environment dictionary with data and it is then the responsibility of the application or framework components to populate or update the dictionary with additional values and write to the response body stream.

Application Delegate

The application delegate is simply an implementation of the Func delegate type where the function accepts the environment dictionary as input and returns a Task. The Task is used to signal when the HTTP application has finished processing the request.

So what is Project Katana. Let’s get to know what Katana is in my next post.