Suppose I have a route like the following:
/api/v1/{organisationId}/resource/{resourceId}
Since there are likely to be a number of different types of resources hanging off an organisation, I'd like a common way of dealing with the organisationId.
What I thought of doing is creating a base controller (inheriting from ApiController, obviously) which would have an OrganisationId property.
Is there any way to get WebApi to pass the organisationId route parameter to a property on the controller, rather than to a parameter on the action method?
How about this?
public int OrganisationId
{
get
{
return Convert.ToInt32(Request.GetRouteData().Values["organisationId"]);
}
}
This is not using the model binding layer and is assuming that organisationId would be present in the route data. It is simple and a bit less flexible than what web API model binding offers.
The downside to reading the route from within the property getter is unit testing could be a challenge. Another possible approach is to explore implementing your own IHttpControllerActivator that sets the OrganizationId property. Yes, for this to work, you will need a base controller or the property defined in the individual controllers, when not derived from the base. If you go with base, you can cast IHttpController type to the base and set the property. Or you can resort to reflection.
Related
I have a method like this in DeliveryController.cs:
[Route("api/Deliveries/Count")]
public int GetCountOfDeliveryRecords()
{
return _deliveryRepository.GetCount();
}
There are other methods with routes using "Delivery" instead of "Deliveries" which are discovered. But why is the plural of the Controller name also found? Does the Web API routing engine really look first for the API call precisely and then, if not found, look for the singular of that?
IOW, when passed "...api/Deliveries/Count" does it first look for DeliveriesController and, when not found, then search for DeliveryController?
When you apply a Route attribute directly to a method, the routing engine knows exactly what's the name of the method mapped to that route through reflection and it doesn't try to locate it based on it's name.
When using attribute routing, you can use any naming you want even if you don't respect conventions.
This route would be completely valid:
[Route("api/whatever")]
public int UnrelatedName()
{
return _deliveryRepository.GetCount();
}
Model Binding creates a new object which it maps the form fields to. It usually requires an empty contructor for this object. However what if you wished to pass a parameter to the ctor for it to say retrieve a record for the object.
I have a feeling that one needs to write a custom model builder which I am reluctant to do.
Is this possible?
Thanks.
I'm using ASP.NET MVC3 and i'm wondering that the default modelbinder binds to public properties but not to public fields.
Normally i just define the model classes with properties but sometimes i use some predefined classes which contains some fields. And everytime i have to debug and remember that the modelbinder just don't like fields.
The question: Whats the reason behind it?
but sometimes i use some predefined classes which contains some fields
While I cannot answer your question about the exact reason why the default model binder works only with properties (my guess is that it respects better encapsulation this way and avoids modifying internal state of the object which is what fields represent) I can say that what you call predefined classes should normally be view models. You should always use view models to and from your controller actions. Those view models are classes that are specifically defined to meet the requirements of the given view.
So back to the main point: fields are supposed to be modified only from within the given class. They should not be accessed directly from the outside. They represent and hold internal state of the class. Properties on the other hand is what should be exposed to the outside world. Imagine that in the property getter/setter you had some custom logic. By modifying directly the field this custom logic would be broken and potentially bring the object into an inconsistent state.
Maybe the reason for ignoring fields is to increase performance of the binder. Instead of searching all the Fields and properties. The Model Binder search for Properties only.
Though I think the Model Binder use cache to improve performance.
DefaultModelBinder exposes a public method:
DefaultModelBinder.BindModel, and a number of protected method available for overriding. All of them listed here.
Besides the model, these method refer to properties only, not fields, like
GetModelProperties,
GetFilteredModelProperties,
GetPropertyValue,
OnXYZValidating,
OnXYZValidated,
OnXYZUpdating,
OnXYZUpdated,
GetXYZValue,
where XYZ stands for either Model, or Property/ies, or both, and so on.
As you can see there is no Fields mentioned with these names whatsoever. As Darin explained no direct changes to Model's state are tolerated by the Binder. Hence no Field in its methods.
And also, you may wish to take a look at another important class: ModelBindingContext. An instance of this class gets passed to the BindModel, and subsequently to BindSimpleModel, and BindComplexModel, depending on model type (string, int,... are considered simple, everything else is complex).
So, this context has the following properties:
ModelXYZ, and
PropertyXYZ.
In other words you have no means to reference the fields in your ViewModel unless you do not override these classes and undertake special actions to do so.
But again, beware of fighting the framework, its always easier to follow it instead.
EDIT: The ModelMetadata class holds all the data needed to bind the model. Its code however, shows no sign of fields, field names, etc. Only properties are referenced and accessed. So, even if you try to inherit and override DefaultModelBinder and ModelBinderContext, you still won't be able to access fiellds, nevermind what their access modifier is: public, private, etc.
Hope this explains most of it.
I wonder if there is attribute (built-in or some open source) for me to tag my controllers with the specific URL segment I want it to use, as in:
[MagicUrlRoute("status")]
public class InternalNameNotToBeRevealed : Controller
{
public ActionResult Show()
{
...
}
}
This way, instead of "/InternalNameNotToBeRevealed/Show" being what the user sees, it will be "/status/Show". This might be nit-picking, but it bothers that I have to use the controller class name as the official URL path.
Now, I do understand I could create a custom-route on global.asax, but that will be a lot of work for hundreds of controllers.
I found this very handy library to do exactly that, but only for actions:
http://maproutes.codeplex.com/releases/view/39888
I appreciate any suggestions.
You could have a listing of the mappings and just call MapRoute in a loop to register all the custom mappings. The mappings could be a dictionary, or you could even scan all your controllers once on App_Start, collect a custom attribute value and then use those to build the mappings. However, I'm not sure how well that would perform for a large number of mappings.
If you wanted a higher-performance mechanism, you'd have to create your own Route. You should be able to do this by inheriting from System.Web.Routing.RouteBase and overloading GetRouteData and GetVirtualPath to do the mapping. When constructing RouteData, you can just provide the existing System.Web.Mvc.MvcRouteHandler as the route handler, and as long as your route data contains 'controller' and 'action' values, it should continue down the MVC pipeline. Then just use the Add method on RouteCollection to add your route. You can take a look at MapRoute in System.Web.Mvc.RouteCollectionExtensions for some insight on how MVC adds it's route.
I am developing an application that involves a type hierarchy and started by defining the models for each type via inheritance. When it comes to writing the corresponding controllers I am not sure how to approach the whole thing in a clean way. Should I write only one controller for the base type that is able to handle derived models or should there be one controller for each subtype? How should the view-controller bindings be set up to work with the different controllers?
You might want to check out SproutCore's new experimental polymorphism support: http://groups.google.com/group/sproutcore-dev/browse_thread/thread/b63483ab66333d15
Here's some information on defining sub-classes and overriding properties and methods:
http://wiki.sproutcore.com/w/page/12412971/Runtime-Objects.
From my (limited) use of Sproutcore, I've only been able to bind 1 view to 1 controller.
As such, if you are planning to use a single view (e.g. ListView) to display your data, then I think you will only be able to bind that view to 1 controller. This means the 1 base type that is able to handle derived models seems to be the way to go.
Typically you populate the content of ArrayController instances with the results of App.store.find calls. SC.Store#find can take an SC.Query instance, which typically looks like:
MyApp.myController.set('content') = MyApp.store.find(SC.Query.local(MyApp.MyModel));
This should return all instances of MyApp.MyModel, including any instances of MyApp.MyModel's subclasses.
The first argument to SC.Query.local can either be an SC.Record subclass or a string referring to the subclass. So if you've got some intermediary SC.Record subclasses, you might want to try using them there.
Controllers should just be proxies for objects, when dealing with single instances of your model. In other words, ObjectController can proxy anything. Here is what I mean in code:
You have two objects, Person and Student.
App.Person = SC.Object.extend({
// person stuff here
})
App.Student = App.Person.extend({
// student stuff here, you have have all Person things because you are extending person.
})
You then want to define controllers:
App.personController = SC.ObjectController.create({
contentBinding: 'App.path.to.person'
})
App.studentController = SC.ObjectController.create({
contentBinding: 'App.path.to.student'
})
note that you would only bind the controller's content to something if the person/student is a result of a selection, or some other flow where bindings fire. In other words, if you set the person manually (say from a statechart, as the result of an interaction), you would still define the controller but would do
App.personController.set('content', person);
You set up the controller differently depending on whether the Person is a 'top level' object in your app, or some intermediate object that gets selected. Also, you might only need one controller, you would only have a studentController and a personController if you were acting on a person and a student at the same time. Both are just ObjectControllers, and those can proxy anything.
Finally, in your view you would bind the relevant view element to the controller:
...
nameView: SC.LabelView.design({
layout: {/* props */},
valueBinding: SC.Binding.oneWay('App.personController.name')
})
...
note that the oneway binding is if the name is not going to be changed on the view, if the view can change the name, then just do a normal binding. Also note the path here. I am not binding to
'App.personController.content.name'
Since the personController proxies the object, you bind to the
'namespace.controller.property-on-object-controller-proxies'
If you are putting a lot of business logic in your controller, you are doing it wrong. Controllers should just be for proxying objects (at least ObjectControllers should be). Business logic should be on the models themselves, and decision making logic should be in statecharts.