A strange ASP.NET MVC friend that I met on my journey to Vagaman

It was a crowded day , more than that it was a hartal day; so there was only few buses expected to operate. After waiting for 2 hrs I got the bus that I was waiting for, it was the only bus that is to go to Vagaman, hill station located in Kottayam- Idukki border of Kerala, India.I was the first guy to get in the bus that was clear empty as a class room on a extra class day in College. I rushed to a window seat so that I can see all the colors dazzling through. When the bus was about to take two young chaps rushed inside bus, I was pretty sure that he was not mallu’s. The only seat that was now empty was the seat next to me. He approached to my seat. I asked him to where are up to. He was also heading to Vagaman. He was a software professional and to my surprise he was also a web application developer same as me, but different framework. He told me he uses ASP.NET MVC for developing his applications. It was the first time I heard the name ASP.NET MVC. The thought that came to my mind first was why should I need MVC, when I can develop application on plain ASP.NET, and to my anxiety I asked him that. To my surprise he told :
You should NOT use ASP.NET MVC if. . .

• You aren’t willing to build on top of the framework
• You rely on 3rd party vendor controls for lots of the UI
• You are not willing to use open-source libraries
Also in order to maintain state in an ASP.NET web forms application, ASP.NET uses encoded data in a hidden form field via a feature called viewstate. Viewstate does pretty well at providing the illusion of a stateful application, but there are times when problems are encountered. For example, in large applications, viewstate can become very large. Large viewstate not only increases your payload across the network, but it can also impact your search engine ranking by pushing readable page content far down in the rendered code. The control over HTML enables developers to build Ajax applications more comfortably, and it adds more interactivity and responsiveness to existing apps. Direct control over HTML also means better accessibility for implementing something that is in accordance with evolving Web standards. In addition, ASP.NET MVC uses interface-based contracts, which allow components to be more easily tested in isolation. As a result, cleaner and more testable code is often promoted as a good reason to embrace ASP.NET MVC. The runtime environment is the same for ASP.NET Web Forms and ASP.NET MVC applications. The view engine can be asp view engine or a razor.
But I again wondered why I should have to write HTML and Javascript when before he could have retrieved all that beautiful information with a simple postback. I asked him this question, he was very quick to respond, meanwhile bus was moving very fast indeed :

 Rob Conerey (Microsoft employee at the ASP.NET MVC team and creator of SubSonic ) explains why developers should learn mvc  after observing questions raised in the community.
In his introduction he starts off by describing WebForms as “The Great Lie”:

WebForms is a lie. It’s abstraction wrapped in deception covered in lie sauce presented on a plate full of diversion and sleight of hand. Nothing you do with WebForms has anything to do with the web – you let it do the work for you.
Rob lists 7 reasons for using ASP.NET MVC or in his own words “7 Reasons To Stop Calling Me A Jerk”:

• Testability
• Control over HTML
• Extensibility
• It Makes You Think
• Differently Javascript Doesn’t Suck
• Learning New Concepts
• It’s Fun
And concludes with:

Bottom line: I’m having fun web programming again and I think that’s pretty motivating, at least for me and my cats. Yet Another Comparison, sure, but hopefully a bit more direct. You have absolutely no reason at all to not learn MVC – but I will concede there may be a reason or two for you to stick with WebForms.
I know many people might think I’m speaking for the rest of Microsoft – hardly. I’m biased and, more importantly, I actually still have my very own brain which forms its own thoughts! I love MVC and I think you will too – just please, please try it before you form an opinion.
It is said that Microsoft initially created ASP.NET MVC (in roughly 2007-08) as a proof of concept to demonstrate that it was possible to apply patterns such as Model-View-Controller (MVC) to ASP.NET. (The MVC pattern, which is frequently used in the design of web sites, aims to separate data, business logic, and the presentation to the user. The challenge in many cases is keeping business logic out of the presentation layer. However, no IT manager will spend money on new software solely because it applies patterns.
ASP.NET MVC provides total control over HTML and it offers cleaner interaction with inline JavaScript. If this statement doesn’t sound exciting enough at first, then consider that it is exactly this freedom that enables the development of pure Ajax solutions without tying a site to a specific commercial framework. To this end, ASP.NET MVC undoes to one of the best-selling points of ASP.NET Web Forms when it was introduced a decade ago, It shielded developers from the details of HTML. In contrast, ASP.NET MVC stays closer to the metal of HTML and HTTP, and it gets rid of the thick abstraction layer built on top of Web Forms (viewstate, server controls, page controllers, event-based page lifecycle).
He told me lets go in detail:
By default, when starting a new MVC project, Visual Studio offer to create a new Unit Test project based on Microsoft’s Unit Test framework. Other Unit tests framework can also be configured to be used by default instead of Microsoft’s solution. The ASP.NET MVC framework includes a flexible URL routing system that enables you to define URL mapping rules within your applications. The routing system has two main purposes:
• Map incoming URLs to the application and route them so that the right Controller and Action method,
• Construct outgoing URLs that can be used to call back to Controllers/Actions (for example: form posts,links, and AJAX calls) Having the ability to use URL mapping rules to handle both incoming and outgoing URL scenarios adds a lot of flexibility to application code.
By default when you create a new ASP.NET MVC Web Application it will pre-define a default /[controller]/[action]/[id] routing rule that you can use (without having to manually configure or enable anything yourself). This should enable you to build many applications without ever having to register your own custom routing rules. In classical ASP.NET form model apps, if the browser is a mobile phone then each page needs to be rendered for the phone or redirect to a separate page for mobile devices, but for ASP.NET MVC all the requests comes in the controller action and this can decide which view to be given back without any change in url.This blog and redirect it to the proper view gives a better idea on this. Also jQuery is shipped with any new project instance of ASP.NET MVC. Since Microsoft announced support for jQuery, it’s been the big buzz in the javascript world. 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
I became so fascinated about this new approach, I asked him to tell more about its architecture, he continued:
MVC is a framework for building web applications using a MVC (Model View Controller) design:
• The Model represents the application core (for instance a list of database records).
• The View displays the data (the database records).
• The Controller handles the input (to the database records).
The MVC model also provides full control over HTML, CSS, and JavaScript.

MVC Archtecture

Layers of ASP.NET MVC

The MVC model defines web applications with 3 logic layers:

The business layer (Model logic)
The display layer (View logic)
The input control (Controller logic)
• The Model is the part of the application that handles the logic for the application data.
Often model objects retrieve data (and store data) from a database.
• The View is the parts of the application that handles the display of the data.
Most often the views are created from the model data.
• The Controller is the part of the application that handle user interaction.
Typically controllers read data from a view, control user input, and send input data to the model.
This code project link is very good for new chaps like you. Also  this official asp.net site also is not bad to start with.
I enquired him where I could get MVC installable’s, he told : Its simple download it from here .

Suddenly the conductor asked us whether we took tickets, irony is that it pasted 2 hrs till we started our journey. We took our tickets. He asked the conductor at what time bus will reach wagamon, to my surprise he asked this in malayalam, our local language. He told me he knows many languages like the MVC application that can be localized easily. Then I asked him how localization done in ASP.NET MVC. He began:
Creating a multilingual website is not an easy task, but it will certainly allow your site to reach more audience. Fortunately, the .NET Framework already has components that support different languages and cultures. The format for the culture name is “-“, where is the language code and is the subculture code. Examples include es-CL for Spanish (Chile) and en-US for English (United States). Every thread in .NET has CurrentCulture and CurrentUICulture objects. The UICulture determines which resources are to be loaded for the page by the ResourceManager. The ResourceManager simply looks up culture-specific resources that is determined by CurrentUICulture. In order to create different views for every culture, we will append the culture name to the name of the view. For example, Index.cshtml (the default view), Index.es-CL.cshtml (Spanish, Chile), Index.ar-JO.cshtml (Arabic, Jordan). The view name that has no ending is considered the default culture. A default culture view will be rendered if the requested culture name is not implemented explicitly.Some people prefer to use a single view for all languages because it is more maintainable. While others think replacing views content with code like “@Resources.Something” might clutter the views and will become unreadable.
To my doubt I asked him how do we determine which version of a view to return to the end user? He told:
There is a header field called “Accept-Language” that the browser sends on every request. This field contains a list of culture names (language-country) that the user has configured in their browser. The problem is that this culture may not reflect the real user’s preferred language, such as a computer in a cybercafé. We should allow the user to choose a language explicitly and allow them even to change it. In order to do this sort of things, we need to store the user’s preferred language in a store, which can be perfectly a cookie. We will create a base controller that inspects the cookie contents first, if there is no cookie, we will use the “Accept-Language” field sent by their browser. The base controller checks if the cookie exists, and sets the current thread culture to that cookie value. Of course, because cookie content can be manipulated on the client side, we should always validate its value using a helper class called “CultureHelper”. If the culture name is not valid, the helper class returns the default culture. After that, when we call “Return” in controller action methods, the view name is modified by the base controller behind the scenes to reflect the correct culture in cookie or header field. This way we make sure that the user gets the right content based on their culture.
For client-side, we should worry mainly about numbers, date and time, and messages since these change from culture to culture. There are many ways to implement client-side localization. But here are two common options:
• Creating standalone localized javascript files for every culture and language.
• Creating a standard common javascript file for all cultures by sticking to Microsoft Ajax Library.
For example, for the file “myscript.js”, you need to create “myscript.es-CL.js”, “myscript.ar-JO.js”, etc. We can reference the javascript files easily from our views by appending culture name to the javascript file :

I asked him to summarize this, he smiled and told:

• Add a base controller from which all controllers inherit. This controller will intercept the view names returned and will adjust them depending on the current culture set.
• Add a helper class that stores the list of culture names that the site will support.
• Create a single view or set of views for every culture and language.
• Create resource files that contain translation of all string messages. (e.g. Resources.resx, Resources.es-CL.resx, Resources.ar-JO.resx, etc )
• Localize javascript files.

It was at that time his phone ringed and I was able to recognize that ringtone of his phone, it was a old malayalam  song ; Meanwhile we reached Vagaman.The breeze was soo cold.


aM what aM

Tagged with: , , , , , , , , , , , ,
Posted in ASP.NET, MVC
One comment on “A strange ASP.NET MVC friend that I met on my journey to Vagaman
  1. Wohh precisely what I was searching for, thanks for putting up.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: