This is a question I asked myself many times. My company uses WebForms, and always I start developing a new application, my problem is managing controls state. With control state I mean things like: "If this ListBox is empty, disable this button, if this GridView is in edit mode and there is a row selected, disable that TextBox, if this button is pressed, refill the DetailsView, etc." Normally, when I finish coding the WebForms application, I have written a lot of code to control all those controls state in the same Page, and that code is messy and error prone. Are there any tecnics I can apply for improving and order the Page's code (distributing it in other clases, for example)?
I've seen some examples of WebForms code where the pages state is controlled using the MVP (Model-View-Presenter) pattern.
The MVP pattern is a variant of the MVC pattern where you have a Presenter class that controls the state of you page. It allows you to extract the code that controls state into a class that is both testable and reusable.
Moving to the MVP pattern if you have used "traditional" WebForms for a while can be challenging, but it will give you much cleaner code if you do it right.
An old but ok article on WebForms and MVP can be found here: http://msdn.microsoft.com/en-us/magazine/ff955232.aspx
You should also google the concept, there are many articles on the subject out there. :-)
You can make it more cleaner using custom userControls.
It's reusable and the code logic is not in your "master" page
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 am quite amused by the MVP Pattern http://webformsmvp.com/
How ever I have certain doubts on the implementation part.
Is it necessary that to use this pattern, I have to implement user controls?
I always thought that user controls are created if we need reuse of controls across pages.
Say if I want to implement and test MVP pattern,I should break my simple page with controls to a lot of user controls so that I can apply the MVP pattern?
What if I have quite a lot of standalone components in my webpage?
Is there any gap in my understanding of MVP?
Help.
It is not necessary to implement user controls to use this pattern, in short. Very briefly, you need a view (could be aspx or wpf or winform or console, etc.), a presenter that'll read from/listen to events from the view, make a call to the model and finally populate view with the right data, that's what MVP pattern is.
edit: this example is simple enough.
You don't have to use user control to use MVP pattern. MVP is GUI pattern that helps you to separate your concern.
For example, You write ASP.NET web page to calculate two numbers, with out MVP or MVC or any other GUI pattern, you would write all this logic in your code behind file which is very hard to test. If you want to test it, then you are bringing lot of extra baggages like ASP.NET framework.
In other hand, you write this app using MVP, you would do this.
View => Dumbest in all three. Doesnt have any or minimun logic. So you dont have to unit test it. It simply "tells" the presenter something happened and does what presenter asks.
Presenter => Controls the flow
Model => Business Logic/persistent logic.
I'm the author of the Web Forms MVP project you mention. This answer is specific to that library (which is just one implementation of the MVP pattern).
No, you do not need to use user controls. If you want, you can make your page inherit from MvpPage and it will then work with a presenter itself.
We recommend that you do use user controls though, even if you aren't using the control multiple times in your site. This lets you keep the view, view model and presenter logic nice and bundled as a logical unit for a particular feature. Pages are then used purely for laying out controls.
I was wondering, whats the best way to handle common HTML controls in ASP.NET? I mean, ASP.NET server controls generate too much crap inside the code so I rather use common controls.
But how about databind and how to manage those common objects correctly (such as combobox, textbox and so on)?
Don't forget that you can always set runat="server" on any control - that includes standard html form controls such as <input> and <select>, and also other elements like <div>. Anything, really.
This means that you can regain control of the html output in your WebForms pages quite effortlessly - as long as you don't need viewstate or any other more advanced databinding/state managing that ASP.NET normally handles for you.
That said, learning to use the ASP.NET MVC Framework is not a bad idea, since it helps you regain control of much more than just the html output. Generally, creating a page in ASP.NET MVC takes a little more work, since there are no drag-n-drop controls like gridview, textbox or even repeater. Instead, you use html helper methods and regular foreach loops, which means you have to type a lot more code. However, the MVC framework is designed so that you won't have to repeat much code anyway.
If you're concerned about the html markup generated by the WebForms ASP.NET engine, i suggest you take a look at ASP.NET MVC. It's purpose is specifically to give you the control you need over the generated html.
If you don't want to start learning ASP.NET MVC, ASP.NET 4.0 WebForms gives you more flexibility in the generated HTML (such as enabling the ViewState for a specific control only, setting the html id's etc.).
As for the databinding, again if you study MVC in depth and start thinking in terms of action -> result you can gain a lot more control and flexibility.
Later edit: I forgot to mention Razor, the new ViewEngine under development at microsoft. It's currently in beta and only inside WebMatrix, a very stripped down 'getting-started type' development platform for ASP.NET. MVC combined with the very clean code you can write using Razor will be in my opinion an important trend-setter in the web development world.
There's a reason ASP.Net controls generate all that "crap". It's so you can databind and manage those objects correctly. Using standard html controls is useful when you don't need direct databinding or if you have no need to manipulate the control through server-side code.
The best way to handle common HTML controls in ASP.Net is not to handle them directly. By using them to handle data and functionality, you're basically neutering .Net. You might as well go back to classic ASP.
I have looked around on the Internet trying to answer this question. It seems to be kind of complicated though! Seems to come up with all sorts of different topics such as the HtmlHelper and other stuff.
Basically. How can you use custom controls with MVC? In a way that avoids doing anything that is frowned upon.
Also, Is it true that with MVC you have to put some simple logic IN THE PAGE? Isn't that what we should be getting away from?
Update: So, Seems you cannot use controls which depend on anything which MVC does away with, such as the postback events and viewstate. Can you make your own then? A control which does only rendering of course.
Can you use ASP.NET controls? Maybe. If the control does not use ViewState or postback events, it will probably work. For example, the LoginView control works just fine. Telerik supports ASP.NET MVC with some of their controls. On the other hand, if the control needs either ViewState or postbacks, then it just isn't going to work. Controls with data binding aren't ideal, since you typically have to use code behind him up. But they will work, if you add code behind.
On the other hand, controls with no knowledge of ASP.NET (such as the jQuery UI controls) work very well.
No, you don't have to put your logic in the page. You just don't put it on a code behind page, either. Instead, use helper methods.
With respect to the second question, the page is exactly where view logic should go. Any other logic should be in your controllers or models.
I'm not sure what you mean by custom controls. You can have ViewUserControls that are rendered via partials to reuse view code. If you are talking about 3rd part controls built for webforms, it's likely they won't work -- at least for awhile. If you absolutely must have them, though, there are ways to mix MVC with traditional webforms in the same site.
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.