Benefits of MVC
MVC v/s Win forms
If you are quite happy with WebForms today, then maybe ASP.NET MVC isn't for you.I have been frustrated with WebForms for a really long time. I'm definitely not alone here. The smart-client, state full abstraction over the web breaks down severely in complex scenarios. I happen to love HTML, Javascript, and CSS. WebForms tries to hide that from me. It also has some really complex solutions to problems that are really not that complex. Web forms is also inherently difficult to test, and while you can use MVP, it's not a great solution for a web environment (compared to MVC).MVC will appeal to you if you want more control over your HTML - want a seamless ajax experience like every other platform has - want testability through-and-through - want meaningful URLs - HATE dealing with postback & view state issues And as for the framework being Preview 5, it is quite stable, the design is mostly there, and upgrading is not difficult. I started an app on Preview 1 and have upgraded within a few hours of the newest preview being available.
Benefits of MVC
The purpose of many computer systems is to retrieve data from a data store and display it for the user. After the user changes the data, the system stores the updates in the data store. Because the key flow of information is between the data store and the user interface, you might be inclined to tie these two pieces together to reduce the amount of coding and to improve application performance. However, this seemingly natural approach has some significant problems. One problem is that the user interface tends to change much more frequently than the data storage system. Another problem with coupling the data and user interface pieces is that business applications tend to incorporate business logic that goes far beyond data transmission.
There are different types of architectures to develop an application namely
a. 1-tier architecture
b. 2-tier architecture
c. Multi-tier(n-tier) architecture
d. MVC architecture
MVC architecture can be represented simply as shown below:
|Model| <= |Controller| <=> |View | <=> |Model
It is a classic design pattern often used by applications that need the ability to maintain multiple views of the same data.MVC architectural pattern separates an application into three main components: the model, the view, and the controller.It makes it easier to manage complexity by dividing an application into the model, the view, and the controller.
Client side code becomes much easier to use since you have more control over the HTML.
Testing is much easier, it provides better support for test-driven development.Testing components becomes difficult when they are highly interdependent.
Supports multiple views. Because the view is separated from the model and there is no direct dependency from the model to the view, the user interface can display multiple views of the same data at the same time. For example, multiple pages in a Web application may use the same model objects
They are proven.You tap the experience, knowledge and insights of developers who have used these patterns successfully in their own work.
They are reusable.When a problem recurs, you don't have to invent a new solution; you follow the pattern and adapt it as necessary.
They are expressive.Design patterns provide a common vocabulary of solutions, which you can use to express larger solutions succinctly.
They are multiple views using the same model: The separation of model and view allows multiple views to use the same enterprise model.
Consequently, an enterprise application's model components are easier to implement, test, and maintain, since all access to the model goes through these components.
Easier support for new types of clients: To support a new type of client, you simply write a view and controller for it and wire them into the existing enterprise model.
Clarity of design: By glancing at the model's public method list, it should be easy to understand how to control the model's behavior. When designing the application, this trait makes the entire program easier to implement and maintain.
Efficient modularity: of the design allows any of the components to be swapped in and out as the user or programmer desires - even the model! Changes to one aspect of the program aren't coupled to other aspects, eliminating many nasty debugging situations. Also, development of the various components can progress in parallel, once the interface between the components is clearly defined.
Ease of growth: Controllers and views can grow as the model grows; and older versions of the views and controllers can still be used as long as a common interface is maintained.
Distributable: With a couple of proxies one can easily distribute any MVC application by only altering the startup method of the application.
Clear separation between presentation logic and business logic.
Each object in MVC have distinct responsibilities. All objects and classes are independent of each other.So change in one class doesn't need alternation in other classes.Easy to maintain the code and future improvements.Good Productivity
You get REST URLS like /category/1/7243
You don't have to use the ".aspx" extensions (you never really did, but now it is easier to avoid).
Very clean, controlled HTML output. Less of what will show up is hidden from you, so you have a lot more control over the generated HTML.
Client side code becomes much easier to use since you have more control over the HTML. One problem with using JavaScript with WebForms is that naming containers cause the controls on the page to have strange names.
Testing becomes much easier. Web forms where very difficult to test. Because of the controllers instead of the pages themselves handling things, testing becomes much easier.
It becomes far easier to optimize URLS for search engines. With WebForms one needed to use URL rewriters which merely hid what the real URL was.
With WebForms there was a sense of state. Pages maintained their state between posts. This made things a little bit easier, but this obfuscation hides how interactions between the client and the server actually occur. MVC gives you much more control over the client-server interaction.
One downside you should be aware of is that ASP.Net MVC doesn't allow the use of the web form controls, default or custom. You'll have to jump through some hoops if you want to use a custom user control on a view.
MVC allows (and encourages) you to write testable code. Even if you're not into the whole TDD development process, MVC allows to easily unit test your application.
You gain complete control over the rendered HTML again. It just looks like a step back from Webforms at the beginning, but is actually very flexible and powerful, once you get the hang of it.
It will take you a lot less time to code the same functionality in asp mvc than in web forms
The code will be a lot more easy to read and mantain.
If you are quite happy with WebForms today, then maybe ASP.NET MVC isn't for you.I have been frustrated with WebForms for a really long time. I'm definitely not alone here. The smart-client, state full abstraction over the web breaks down severely in complex scenarios. I happen to love HTML, Javascript, and CSS. WebForms tries to hide that from me. It also has some really complex solutions to problems that are really not that complex. Web forms is also inherently difficult to test, and while you can use MVP, it's not a great solution for a web environment (compared to MVC).MVC will appeal to you if you want more control over your HTML - want a seamless ajax experience like every other platform has - want testability through-and-through - want meaningful URLs - HATE dealing with postback & view state issues And as for the framework being Preview 5, it is quite stable, the design is mostly there, and upgrading is not difficult. I started an app on Preview 1 and have upgraded within a few hours of the newest preview being available.
Benefits of MVC
The purpose of many computer systems is to retrieve data from a data store and display it for the user. After the user changes the data, the system stores the updates in the data store. Because the key flow of information is between the data store and the user interface, you might be inclined to tie these two pieces together to reduce the amount of coding and to improve application performance. However, this seemingly natural approach has some significant problems. One problem is that the user interface tends to change much more frequently than the data storage system. Another problem with coupling the data and user interface pieces is that business applications tend to incorporate business logic that goes far beyond data transmission.
There are different types of architectures to develop an application namely
a. 1-tier architecture
b. 2-tier architecture
c. Multi-tier(n-tier) architecture
d. MVC architecture
MVC architecture can be represented simply as shown below:
|Model| <= |Controller| <=> |View | <=> |Model
It is a classic design pattern often used by applications that need the ability to maintain multiple views of the same data.MVC architectural pattern separates an application into three main components: the model, the view, and the controller.It makes it easier to manage complexity by dividing an application into the model, the view, and the controller.
Client side code becomes much easier to use since you have more control over the HTML.
Testing is much easier, it provides better support for test-driven development.Testing components becomes difficult when they are highly interdependent.
Supports multiple views. Because the view is separated from the model and there is no direct dependency from the model to the view, the user interface can display multiple views of the same data at the same time. For example, multiple pages in a Web application may use the same model objects
They are proven.You tap the experience, knowledge and insights of developers who have used these patterns successfully in their own work.
They are reusable.When a problem recurs, you don't have to invent a new solution; you follow the pattern and adapt it as necessary.
They are expressive.Design patterns provide a common vocabulary of solutions, which you can use to express larger solutions succinctly.
They are multiple views using the same model: The separation of model and view allows multiple views to use the same enterprise model.
Consequently, an enterprise application's model components are easier to implement, test, and maintain, since all access to the model goes through these components.
Easier support for new types of clients: To support a new type of client, you simply write a view and controller for it and wire them into the existing enterprise model.
Clarity of design: By glancing at the model's public method list, it should be easy to understand how to control the model's behavior. When designing the application, this trait makes the entire program easier to implement and maintain.
Efficient modularity: of the design allows any of the components to be swapped in and out as the user or programmer desires - even the model! Changes to one aspect of the program aren't coupled to other aspects, eliminating many nasty debugging situations. Also, development of the various components can progress in parallel, once the interface between the components is clearly defined.
Ease of growth: Controllers and views can grow as the model grows; and older versions of the views and controllers can still be used as long as a common interface is maintained.
Distributable: With a couple of proxies one can easily distribute any MVC application by only altering the startup method of the application.
Clear separation between presentation logic and business logic.
Each object in MVC have distinct responsibilities. All objects and classes are independent of each other.So change in one class doesn't need alternation in other classes.Easy to maintain the code and future improvements.Good Productivity
You get REST URLS like /category/1/7243
You don't have to use the ".aspx" extensions (you never really did, but now it is easier to avoid).
Very clean, controlled HTML output. Less of what will show up is hidden from you, so you have a lot more control over the generated HTML.
Client side code becomes much easier to use since you have more control over the HTML. One problem with using JavaScript with WebForms is that naming containers cause the controls on the page to have strange names.
Testing becomes much easier. Web forms where very difficult to test. Because of the controllers instead of the pages themselves handling things, testing becomes much easier.
It becomes far easier to optimize URLS for search engines. With WebForms one needed to use URL rewriters which merely hid what the real URL was.
With WebForms there was a sense of state. Pages maintained their state between posts. This made things a little bit easier, but this obfuscation hides how interactions between the client and the server actually occur. MVC gives you much more control over the client-server interaction.
One downside you should be aware of is that ASP.Net MVC doesn't allow the use of the web form controls, default or custom. You'll have to jump through some hoops if you want to use a custom user control on a view.
MVC allows (and encourages) you to write testable code. Even if you're not into the whole TDD development process, MVC allows to easily unit test your application.
You gain complete control over the rendered HTML again. It just looks like a step back from Webforms at the beginning, but is actually very flexible and powerful, once you get the hang of it.
It will take you a lot less time to code the same functionality in asp mvc than in web forms
The code will be a lot more easy to read and mantain.
1 comment
Thank u..
Post a Comment