Wednesday, 25 June 2014

MVC Basics Part 1



In this post we will be getting basic idea about MVC. Whenever I head MVC the very first question that came to my mind is what actually MVC is? and from here my search started but now I have gained enough knowledge about MVC that I will directly start with it without taking much time of yours.

What actually MVC is
ASP.NET MVC is a design pattern or a software architecture that separates domain/application/business logic from the rest of the user interface. It does this by separating the application into three parts: the model, the view, and the controller. To understand the distinctive aspects and design goals of ASP.NET MVC, it’s worth considering the history of Web development so far—brief though it may be.

  • Common Gateway Interface (CGI)
  • Microsoft Internet Database Connector (IDC)
  • Active Server Pages(ASP)
  • ASP.NET Web Forms 1.0/1.1
  • ASP.NET Web Forms 2.0
  • ASP.NET AJAX
  • ASP.NET Web Forms 3.5
  • ASP.NET MVC 1.0
  • ASP.NET MVC 2.0
  • ASP.NET Web Forms 4.0
  • ASP.NET MVC 3.0
  • ASP.NET MVC 4.0
  • ASP.NET Web Forms 4.5
What is wrong with Traditional ASP.NET Web Forms
Few of the shortcomings are
  • View State weight: The actual mechanism for maintaining state across requests (known as View State) results in large blocks of data being transferred between the client and server. This data can reach hundreds of kilobytes in even modest Web applications, and it goes back and forth with every request, leading to slower response times and increasing the bandwidth demands of the server. 
  •  Page life cycle: The mechanism for connecting client-side events with server-side event handler code, part of the page life cycle, can be extraordinarily complicated and delicate. Few developers have success manipulating the control hierarchy at runtime without getting View State errors or finding that some event handlers mysteriously fail to execute. 
  • False sense of separation of concerns: ASP.NET’s code-behind model provides a means to take application code out of its HTML markup and into a separate code behind class. This has been widely applauded for separating logic and presentation, but, in reality, developers are encouraged to mix presentation code (for example, manipulating the server-side control tree) with their application logic (for example, manipulating database data) in these same monstrous code-behind classes. The end result can be fragile and unintelligible. 
  • Limited control over HTML: Server controls render themselves as HTML, but not necessarily the HTML you want. In early version of ASP.NET 4 the HTML output failed to meet with Web standards or make good use of Cascading Style Sheets (CSS), and server controls generated unpredictable and complex ID attribute values that are hard to access using JavaScript. These problems are much improved in in ASP.NET 4 and ASP.NET 4.5, but it can still be tricky to get the HTML you expect. 
  • Leaky abstraction: Web Forms tries to hide away HTML and HTTP wherever possible. As you try to implement custom behaviors, you frequently fall out of the abstraction, which forces you to reverse-engineer the postback event mechanism or perform obtuse acts to make it generate the desired HTML. Plus, all this abstraction can act as a frustrating barrier for competent Web developers. 
  • Low testability: The designers of ASP.NET could not have anticipated that automated testing would become an essential component of software development. Not surprisingly, the tightly coupled architecture they designed is unsuitable for unit testing. Integration testing can be a challenge, too.
Web Development apart from Microsoft
Outside Microsoft, Web development technology has been progressing rapidly and in several different directions since Web Forms was first released. Aside from AJAX, there have been other major developments.
  • Web Standards and REST : The drive for Web standards compliance has increased in recent years. Web sites are consumed on a greater variety of devices and browsers than ever before, and Web standards (for HTML, CSS, JavaScript, and so forth) remain our one great hope for enjoying a decent browsing experience everywhere. At the same time, Representational State Transfer (REST) has become the dominant architecture for application interoperability over HTTP, completely overshadowing SOAP (the technology behind ASP.NET’s original approach to Web services). REST describes an application in terms of resources (URIs) representing real-world entities and standard operations (HTTP methods) representing available operations on those resources. 
  • Agile and Test-Driven Development :  It is not just Web development that has moved on in the last decade—software development as a whole has shifted toward agile methodologies. This can mean a lot of different things, but it is largely about running software projects as adaptable processes of discovery and resisting the restrictions of excessive forward planning. Test-driven development (TDD), and its latest incarnation, behavior-driven development (BDD), are two obvious examples. The idea is to design your software by first describing examples of desired behaviors (known as tests or specifications), so at any time you can verify the stability and correctness of your application by executing your suite of specifications against the implementation. 
  • Ruby on Rails : In 2004, Ruby on Rails was a quiet, open source contribution from an unknown player. Suddenly fame hit, transforming the rules of Web development. It’s not that Ruby on Rails contained revolutionary technology but that the concept took existing ingredients and blended them in such a compelling and appealing way as to put existing platforms to shame. 
  • Node.js : Another significant trend is the movement toward using JavaScript as a primary programming language. AJAX first showed us that JavaScript is important; jQuery showed us that it could be powerful and elegant; and Google’s open-source V8 JavaScript engine showed us that it could be incredibly fast. Today, JavaScript is becoming a serious server-side programming language. It serves as the data storage and querying language for several non relational databases, including CouchDB and Mongo, and it is used as a general-purpose language in server-side platforms such as Node.js.
and many more.
  
Why one should use MVC
  • Separation of concerns: The separation the three components, allows the re-use of the business logic across applications. Multiple User Interfaces can be developed without concerning the codebase.Developer specialization and focus:  The developers of UI can focus exclusively on the UI screens without bogged down with business logic. The developer of Model / business can focus exclusively on the business logic implementations, modifications, updations without concerning the look and feel and it has nothing to with business logic. 
  • Parallel development by separate teams:  Business logic developers can build the classes, while the UI developers can involve in designing UI screens simultaneously, resulting the interdependency issues and time conservation. UI updations can be made without slowing down the business logic process .Business logic rules changes are very less that needs the revision / updations of the UI. 
  • Multiple view support : Due to the separation of the model from the view, the user interface can display multiple views of the same data at the same time. 
  • Full control over HTML rendered. No renaming of HTML IDs. 
  • No ViewState (Stateless).  
  • Enables Test Driven Development (TDD).  
  • Easy integration with JavaScript frameworks. 
  • RESTful URLs that enables SEO. Representational state transfer URLs example.  Controller/Action/Parameters, which is user friendly, no URL rewriting required.  
  • Supports multiple view engines (aspx, Razor).
 This was just a brief introduction about MVC. In next post we will be creating a sample MVC application for better understanding.




No comments:

Post a Comment