In traditional ASP.NET Web Form applications, UserControls are a great way to encapsulate functionality so that it can be reused. However, UserControls don't fit well into the MVC model. They often make heavy use of ViewState and they blur the seperation of concerns that MVC promotes.
My question is, how do you best bundle a piece of functionality so it can be shared across MVC applications?
As an example, consider a from/to date-selector UserControl that:
allows a user to select two dates, either using a javascript overlay or by typing in day, month and year into seperate fields
can be configured to default to either today and tomorrow's dates or to dates of the developer's choosing
validates the dates that comes back from the user to ensure the from date is before the to date
exposes From and To properties that can be accessed by code-behind
How would I best build something like this in .NET MVC so that I can easily reuse it?
Note that to fully emulate User Control's functionality the MVC component would have to manage the submitted form data and validation - not just the presentation.
In general I would agree that user controls are nice in terms of encapsulating UI stuff, but I don't think too much has really changed in MVC. If I remember right re-using user controls across classic Asp.net projects was a pain and was never really the best way to truly create reusable components. Most UI toolkits that you bought for classic ASP.net didn't give you user controls, they gave you essentially server controls and javascript controls.
In your example, I would probably create or find a jquery (or ur framework of choice) plugin that did what you wanted on the client side. You could also build a C# wrapper around it similar to what Telerik did with some of the jquery UI controls. I do think that the word code-behind and even viewstate will disappear from your vocabulary the more you get into MVC.
If you look at what open source projects are out there for MVC you will get your answer in terms of what you should be doing.
The MVC Contrib app adds a lot of features by creating extension methods and helpers. Their grid control is a typical way to create a reusable component that you could use across projects
Telerik, created some extensions that wrap jquery controls and do asset management.
Finally I think if you look to the future, MVC has areas, which if I interpret it right will give you the ability to break your project apart into multiple smaller projects.
Besides what is already suggested, ASP.NET MVC v2 will have generic templated input controls, see here. You can read how other people do similar techniques, for example, here:
We have
exactly 1 method call for generating a
form element, “Html.InputFor”. As
part of that “InputFor”, it examines
an input specification, that collects
the PropertyInfo, any attributes, the
type, any modifiers called, and
selects an appropriate InputBuilder.
Call InputFor(p => p.Id) and Id is a
GUID? That creates a hidden input
element. Call InputFor(p =>
p.Customer.Address) and Address is a
complex type? That looks for a
partial with the same name of the type
Having considered the helpful answers from others, I will have a go at answering my own question.
It seems to me that the key difficulty with emulating UserControls in MVC is that they crosscut the concerns that MVC aims to seperate. The from/to date selector UserControl in my example incorporates elements of Model, View, Control and interation. UserControls' ability to bundle all this together is exactly the reason that they don't fit well into MVC.
That means that to create a psuedo-UserControl in MVC requires four seperate pieces:
A Model class - in this case an Interval class or similar
A PartialView that knows how to render the Model to HTML
A jQuery script to layer interactivity on top of the PartialView's HTML
A ModelBinder that can deserialise postdata into an instance of the Model class.
The ModelBinder is important because it deals with data coming back from the user. Without it, every Controller that wanted to display a to/from date selector in any of its Views would have to know how to assemble the six postdata fields - and how to cope if they were invalid or some were missing.
Two ways that I can think of. A partial view though this doesn't really transfer well from app to app because you are moving around ascx files. Not a big pain but not my flavour.
I prefer to use WebControls. They are super easy in mvc and all you need to do is reference the library in the project and possibly in your config file and there you go.
I think some of the answers have missed out on the postback functionality of controls. One way you could handle that is to pass any generic information via ViewData when rendering your partial view. That could then post back to its own control, which in turn could redirect to the UrlReferrer.
Its a little messy and use of UrlReferrer poses a security risk. But it is one way around the problem
You can create a jQuery plugin.
As user-controls provided in ASP.NET Webforms, MVC provide a lot of ways to make the controls and code that can be reused in other app.
Using Partials If your partial code have some C# logic and render the html using Razor/aspx code then it's bst to maintain them in razor file.
Write JavaScript Functionality as plugin If you maintain your code and write it as better as it can be used in other app then it would be a huge advantage for you. Next time when you work on other app just open this solution copy it and modify it. Write JavaScript code that can be used as plugin maybe take some more brainstorming.
Write Code As a Separate C# library If some code is too common for every app you make.for example you write a member authentication system or some global function (C#) that are used in every app you made then maintain them in a separate solution so it can be used in other app you made whenever you trying to make a new app in future.
Related
What are the disadvantages to using webparts in asp.net? Are they losing their popularity?
I was planning on creating a user defined Dashboard and was thinking of using Webparts, is this the way to go or is there another way of doing customisable dashboards these days? I would prefer not to have to use a 3rd party product.
To me, webparts are more of a sharepoint thing these days.
Other than that, with some design you can get all you need with user controls and some classes of your own to get common functionality and layout sorted out.
Say you have a base class called DashboardWidget that inherits from WebControl here you could define a overridable method
ProcessDataSource -> executes a query to a database or service and formats the results for presentation
And in the prerender method (or something similar along the asp.net lifecycle) you call ProcessDataSource (you could use the DataSource property most controls already have).
Then you inherit from DashboardWidget to make your controls and in the render method you override ProcessDataSource to get the info the way you need and the Render method to setup what to display.
Ideally you should define your own data source class to have a single place to define where to connect, how, credentials, etc..
As for the layout, newer versions of asp.net include several layout option you may use (and there is always pure html if you want)
I'm shooting from the hip a bit here, but that's a way to do it without involving webparts, that to me, are not that popular outside of sharepoint.
Hope anything of this helps
We have an ASP.Net ScriptControl that is shared between web app projects. One project is being converted to MVC 3 and the shared control needs to be used but of course MVC doesn't have controls or view state.
My ideal solution would be to wrap the control in a html helper so it can be placed on the view. Then, I can send/receive data to/from the control inside the helper.
Is it possible AND is it decently trivial to do so?
As long as it doesn't rely on ViewState or Postback, yes, you usually can.
To be safe in this scenario I would include an ASPX page in your solution rather than attempting to hack it to work. It 'can' work - at times but behavior can be buggy depending what it is looking for behind the scenes so it can be a hack.
Is it my understanding that Helper methods are really the place where you can do the hard core logic that we would have done in lets say custom controls in ASP.NET? For instance I work for a .com which uses classic ASP.NET. The nature of our site is VERY complex, so we reuse and render different forms for thousands of products. Every product could have a different configuration form. We have a very complext RenderForm.cs custom server control that performs all the logic. Based on some configuration settings from a table in the DB, it says ok, for Product 1123 it reads the setup (that our users confugure form our internal admin system) and takes that and spits out the dynamic form (using literal controls and what not) to the p age.
So I'm thinking MVC now. Yea yea, it's all done in the View. Well partially. You're still going to have a need to have some custom logic in some .cs where it's not all embeded in your view. That would be foolish to think you're not going to have some class that will spit out some HTML..like some very hard core extensive helper methods.
So my question is, are helper methods or class where you now do your custom server control type of logic? it's basically kind of the same concept in that you need a place to put your "hard core" HTML rendering logic in some class other than a controller. Your controller is not responsible for rendering. So helper methods I guess are the so-called custom server controls in a way that I have in classic ASP.NET, figuratively speaking. I just need a yes or now on is the consensus that helper methods is the place to do all my hard core reusable logic that spits out html to the page and where I can embed custom controls into my view? Looks like it.
"Helpers are essentially static classes, designed to contain the UI logic that otherwise clutters up your UI. Think of these as UI utilities." link text
Yes, that is right on. If you do it right, you will start with the HTML helpers that MVC gives you, and you will gradually build up your own set of helpers that do even more and more for your specific project. You can get to the point where your view has only a few lines of code, which say something like, "Render entire view for Product 1123". The helpers will become your own "language" of renderers specific to your project, and you will be applying configuration, validation and everything else in a very DRY (Don-t Repeat Yourself) manner. It's phenomenal.
Update: Of course, only presentation stuff should go in your helpers. The goal is to stay DRY in your views. You still need to be careful to put into your ViewModels the things that belong in the ViewModels.
I would say "no"... or rather "only where you have to". More often than not, you can instead do the logic in the Controller (or a Service) and end up passing all the data required back to the View in ViewData. Somtimes this will mean multiple Views from one ControllerAction, less often it will mean logic in your View, and occasionally it means HtmlHelpers.
When you decide to use Helpers, it should be with the consideration that this means generated markup that won't be... well, in your markup. If you have (or later hire) a designer, that can be a problem. Or if you need to make a minor change to your layout, where do you go first? Your View or your Helpers?
[Edit] Also should ask yourself this: where is my code more easily unit tested? In a Service class which is just handing back View Data, or in a class that builds entire chunks of HTML and returns them as a String? If you're using TagBuilder, as you probably should be, then any change in the implementation of TagBuilder (even a change of whitespace handling) will break tests on a Helper without your code changing.
I'm not saying "don't use Helpers", I'm saying "don't abuse Helpers".
A video tutorial says I should use databinding to put data on my webpage. Is this the right thing to do?
It feels wrong to do it. Shouldn't there be a separation of concerns? The view should be separated from the code that connects to the database? In the aforementioned video, he connects to the database without going through a data access layer. What about the presenter/controller? It seems like we are completely bypassing those layers, going around the architecture.
It's important to realise that, when Microsoft produce a new UI technology, at least 2/3rds of it is designed to make it easy for newbies to slap together very simple 2-tier demo apps. I'm not saying this is a bad thing - after all, it helps us get up to speed on the technology quickly. However, when you are writing a proper n-tier app, then it's important to know which bits of the technology can and cannot be used.
For example, in ASP.NET WebForms, you should voluntarily restrict yourself as follows:
Don't use any data source control except for ObjectDataSource, and only use that for binding the Model to the View.
Don't use validation controls to validate input controls. Instead, pass all data to the Business Layer for validation and just display the resulting error messages on screen.
Don't use the built-in sorting/filtering/paging functions of the GridView. Instead, implement your own sorting/filtering/paging mechanism in the Business Layer.
To answer your original question: yes, data binding is very useful, as long as you bind to the Presentation Layer Model, rather than to a real data source.
Jonathan, you're thinking about ASP.NET MVC, whereas that tutorial is written for ASP.NET (which MVC developers like to refer to as ASP.NET Webforms). Have a look at the ASP.NET MVC tutorials here: http://www.asp.net/mvc/learn/
Keep in mind that although both have ASP.NET in the name, they're completely different programming philosophies. Webforms tries to mimic a stateful, event-driven form, like a Winform application. MVC, on the other hand, seperates it into models, views, and controllers, which fits very well with the web's stateless and request/response cycle.
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.