I don't have real understanding of the MVC model or Architecture yet but what I read and see is that it separated the 'Concerns' that is the presentation UI and logical code, right? But I know that WebForms Architecture also has a code behind model which then separates the code and UI.
Is there something else also in MVC which further separates the stuff around?
The main difference between MVC and WebForms is that in WebForms it is the view that receives the request (/foo.aspx), while in MVC it is the controller (/controller) which will manipulate the model and choose the appropriate view to render. Another important difference is that all the HTTP Context stack (Request, Response, Session, ...) has been abstracted behind abstract classes and interfaces in ASP.NET MVC which allows for better separation of concerns and unit testability in isolation. You also have far more control over the generated markup in ASP.NET MVC in contrast to WebForms where the markup is essentially generated by server side controls.
Code-behind is specifically what makes UI tightly coupled to business logic in WebForms -- the code-behind is part of the UI.
Using controllers instead of code-behind is one of the primary ways in which MVC decouples these concerns.
The easiest way to think about this is that the .aspx and code behind are essentially two different views of the same component, the UI. It's completely possible to use code behinds with MVC (if you're using the webforms view engine), but both the view and the code behind are considered part of the UI. The controller is a seperate entity, as is the model.
Code-behind is specifically what makes
UI tightly coupled to business logic
in WebForms -- the code-behind is part
of the UI.
Only if you choose to let it.
Business logic will not be coupled to UI if you choose to have seperate business layer/tier and implment an appropriote UI layer pattern such as MVP/MVC/MVVM.
Id argue a n-layer design with an MVP pattern in webforms can offer even greater seperation of concerns than asp.net MVC but requires alot more upfront design.
Asp.Net MVC forces better seperation out of the box. Its baked into it.
This is good for developers who might not know any better. With webforms it is completly up to the architect/developer to select the level of sepearion required, a double edged sword because if you're experienced with the platform can do some great stuff, but if your new to it or coming from a classic asp style of development you may make a mess of it without some guidance.
Biggest plus I see for asp.net MVC over webforms isnt soc, or testability (as they can be acheived in webforms) it's the ability have better control over markup (if you need it) and the more web centric focus (again, if thats what you need).
Related
I need to write a web page which I need to interact with Grid entry/edit.
I choose ASP.Net MVC and LINQ TO Entity Framework.
What my problem is I have two option to choose at View Layer.
ASPX
Razor CSHTML
Could someone please give me suggestion which one is more suitable to interact Grid Entry Edit process? And Why?
If there are any references , please let me see them also.
[UPDATED]
JQUERY Grid
Telerik Grid for ASP.NET MVC
Razor Web Grid
After I searching through at Google, I get more than one Grid Controls.
I still wondering which one I need to use.
When I was writing with net 2.0 framework, I use template control from GridView Control in traditional way to put Combo or some other controls to attatch with GridView.It is really useful.
So What i thinking is, at asp net MVC 3 version, should i also use these traditional technique as well.
Could anyone please give me suggestion?
Razor is simply more concise. Both Razor and WebForms will offer the same basic functionality, but Razor results in Views that are much less cluttered and therefore more easily understood.
View engines have nothing to do with this. They both provide the same functionality, which you use is up to you and your preference.
There are many kinds of grids available for MVC, but MVC itself does not come with a grid. You either have to build the grid yourself, or use a third party component, most of which are jQuery based. Again, it's up to you what to use, as it's your preference.
All you can do is choose something and go with it. If it doesn't work for you, choose something else. MVC is a technology that requires you to know much more about how the framework works. If you want point and click and drag and drop, you should go back to Web Forms.
.chtm provides "Mapping of Data(or Business) objects that Your UI needs to Render(the html)" in a isolated way, so you can control the Test Cases for your UI as well as your Business Object Unit testing, which is Hard using ASPX since you have to create HTTPContext and (SSL and all crap) just to TEST your Business Logic..in short .cshmt is more NEATLY TESTABLE than aspx.
I've been learning about MVC for a while, and I think I pretty much understand what it's all about. But there is one thing I don't yet understand: I keep hearing with MVC that there is no viewstate nor postback.
Can someone explain what this means in simple terms?
Try this SO answer which addresses the same question.
Extra info after comment/question:
ASP.Net web forms can use viewstate to store the state of server controls on the page and to manage invocation of server side events such as a button click. The idea is to present a programming model that is similar to the Win Forms approach to make it easier for Win Forms developers to transition and knock out browser based apps. To learn about it in depth you should hit google and learn about the asp.net page life cycle which will explain the overall process and explains where viewstate processing fits in. Here's a pretty good explanation.
ASP.Net MVC is a different programming model that uses different view engines to generate your markup - i.e. the content that actually streams back to your browser client. To an extent it removes a lot of the "magic" that web forms introduced but in return you can produce more standard markup and have greater control over what will be rendered to the client. If you're learning MVC take a look at the NerdDinner sample chapter which is a good tutorial as well as the MVC Music Store. Throughout those are good intros to doing MVC.
MVC doesn't use/need viewstate or postbacks as it's a different programming model. Which is better/more appropriate for any given project is a big debate that I'll let others have as I think both have their strengths and can be useful in different scenarios (although I personally mainly use MVC now...). You're right that things are done differently... you can't just work with the simple event driven approach that web forms imitates but then MVC has lots of strengths of its own which you'll find across countless blog posts comparing webforms vs MVC.
MVC Do not have viewstate and session but you can use TempData Object instead of viewstate.
in your controller you can bind like this TempDate["MyKey"]="My Value" and in the next request you can get your value in action like String s=TempData["MyKey"]
I've been reading about MVC in which the authors suggest that testability is one of the major strengths of MVC. They go to compare it with ASP.NET WebForms and how difficult it is to test the code behind in WebForms.
I do understand it's difficult but can someone explain how unit tests were written to test code behind logic in the old days?
In the old days I tested aspnet webforms using the pattern Model View Presenter. I was able to test code with this pattern because I abstracted the conditional logic / loops / etc into a separate class that didn't live inside the webforms framework.
What was left in the webforms codebehind was nothing more than a few properties and a call in the page load to init the presenter class itself.
Then each event handler would simply pass off the work to the presenter class.
I've spent a great deal of time with this pattern and found that it makes things much more test friendly but it's a great deal of work compared to aspnet mvc
The code behind are plain methods in a class (the only difference with another class is that this class inherits from the Page object)
So it is testable.
most problems arise because the methods were tightly coupled to web.ui controls like the grid; they were not so easy to fake.
If you didn't fake the UI controls, you were also testing the inner workings of the UI controls which is a little overdone.
I have developed a webapplication in both ASP.NET MVC and ASP.NET Webforms and i'm wondering isn't Webforms following the rules of the MVC Pattern just the as ASP.NET MVC is?
I mean we have the .aspx file which holds the visual (HTML and JavaScript) and then the code behind file which controls the user interaction and data for the .aspx file. Then we could make a Repository lager for fetching and doing stuff with data.
Isn't this the same as following the rules of the MVC Pattern? View for visual, Controller for controlling user interaction and data for the Views and the Model fetching and doing stuff with data?
I know ASP.NET MVC and Webforms handles Postbacks and URL handeling differently, but im not comparing the two ASP.NET techniques, but the MVC Pattern in generele for the two techniques.
ASP.NET Webforms is definitely not following the MVC pattern.
In MVC you have three elements, the Model, the View, and the Controller.
In ASP.NET Webforms, you have your Page (codebehind and the markup are compiled into a single object, not seperate), and whatever data is being shown. You really have no controller. You make a requrest directly to the page rather than a controller and the page is responsible for both working with the data and rendering the page. Definitely not seperated like MVC would be.
Just the fact that you're not using the codebehind in your aspx page should give you a hint that there are some pretty substantial differences between MVC and webforms... You aren't using the codebehind, are you?
Not to mention how hard it is to test a Webforms page.... You are testing your code, right?
You can indeed use an MVC pattern with Web Forms, but all you are doing is adding additional classes or layers to the postback. The previous answers here are coming from a purist point of view that is more clear separations built into the technology. But, there is nothing preventing you from using different classes to represent the Model the View and Controller and only have your WebForms bind to the View. All of the communication is still done on postback, but it is still technically MVC and still the correct pattern to use.
Reference:
http://msdn.microsoft.com/en-us/magazine/ff955232.aspx
Are there some things I cannot do with ASP.NET MVC?
Things that are only possible with ASP.NET WebForms,
or extremely much easier with WebForms?
We consider using ASP.NET MVC for a new project.
But I wonder if there are some obvious things we will not be able to do with ASP.NET MVC when compared to WebForms, or places where we will have to spend a lot of time with ASP.NET MVC.
The biggest one would be using existing 3rd party controls on your form. Most of the inbuilt controls are pretty easy to reproduce, but if you have a pet 3rd party control, you might have to host that on a regular (non-MVC) aspx page (luckliy this is supported).
Likewise, "web parts"
Also - the feature where ASP.NET uses different html for different clients (mobile, etc) becomes... different; you wouldn't want to do this by hand, but in reality most clients now work with standard html, so it is less of an issue in the first place.
Some things like i18n via resx files need extra work than is in the vanilla MVC template, but the samples are there on the internet.
One point... MVC is licensed only for MS/ASP.NET; so one thing you can't do (without violating the terms, as I understand it) is to run it in mono/Apache - but IANAL.
Now consider the things you can do with MVC, that you can't (or are hard) with vanilla:
routes instead of pages
automated input resolution (action arguments)
proper html control...
...enabling jQuery etc for simple AJAX
separation of concerns
testability
IoC/DI
multiple templating options (not just aspx/ascx)
re input resolution:
public ActionResult Show(string name, int? page, int? pageSize) {...}
will pick "name", "page" and "pageSize" off (any of) the route, query-string or form - so you don't have to spend lots of time picking out request values.
re templates - aspx/ascx aren't the only templating options. For example, see here; or you can write your own if you like... The view is not tied to ASP.NET controls at all.
Validation is not as easy as in WebForms. In Webforms you can add a validator and just set a property that enables clientside validation. You can localize the errormessage. The localization works clientside and serverside.
There is no out of the box clientside validation in MVC and you need to find a way to localize clientside errormessages.
Localization itself is different. Ressources obviously by default dont exist per page, because there is no page. But there is a good way to have ressources per view.
I still did not check, if it is possible to set SSL-required per folder.
EDIT
The story is different with MVC3. There is a good validation support now.
There are still things that are not implemented in MVC. The biggest issue for me is a complete implementation for donut cashing and partial cashing. There is some improvement in MVC3 in this area but it is still not complete. Anyway stay tuned: the MVC team seams to be aware that this is something they should work on.
The big one is Controls. User Controls are not available with ASP.NET MVC. I have even gone so far as to try using code like this:
new Label().RenderControl(...ResponseStream...);
No dice.
Of course, as a part of that, there is no need for view state, so that isn't in there.
Server controls do work, though.
As Marc said, third party tools and (serverside) webcontrols cannot be used. So slapping something together quickly by dragging and dropping a few controls on a form (like a grid and a dataaccess control) is no longer an option.
But with the codegeneration etc. you can still make something quickly. And you still have the above option if you need something quick.
I think view-state is non existent in MVC. You will have to track your own view state in some other way than the built in view-state in non MVC projects.
EDIT:
According to comments: "Getting rid of ViewState is an advantage not a disadvantage". – Craig
ASP.NET Ajax is not working with ASP.NET MVC so no UpdatePanel (due to lack of postback). Fortunately there is built-in ajax (Ajax.Form) which can be used to perform partial updates not to mention jQuery which is shipped by default with the Visual Studio project template.