Model Binding isn’t just for the web
It’s a given that your web framework of choice has some form of model binding built-in. Maybe you’re lucky enough to have Content Negotation on top of that but regardless, there is some mechanism to transform the incoming HTTP message to a well-formed type for you to consume.
When I first started using these binding mechanisms, I found myself asking a few questions:
- Is there a way to extend the standard converters?
- Is there any easy way to distribute common extensions?
Frameworks at the time were working to answer those questions and that was fine. But then I started to wonder some more:
- What if we could do conversions more conventionally?
- What about common practices with value types?
- How about we bind common properties via some known service for testing (e.g., CurrentDate, CurrentUser)?
You’re probably thinking that this the part where I do my obligatory plug for Fubu. Well, you’re absolutely right.
Model Binding in Fubu
Most people are not aware of the separation between FubuMVC and FubuCore. That is, they hear about something in the world of Fubu and think that they would only be able to leverage it if they were using the whole stack. Well, that’s just not true and plenty users of HtmlTags would tell you all about it. I say this because Model Binding just happens to be another gem that is found in FubuCore.
Our binding uses the notion of a source of values (aka IValueSource). My common explanation for this is: “Imagine if you iterated over your design a few times going from a dictionary, to a value type, abstracted that, and then made everything compatible with testing and diagnostics”. That would be IValueSource.
So, why do you care? And why is this applicable outside of the web? Let’s look at some example IValueSource implementations:
Web
This one’s a no-brainer. There are value sources in FubuMVC that make route and request data available to the binder.
Settings
This one is a favorite that I take for granted. Settings data can come from anywhere (app/web config, database, etc.). You can adapt that information into an IValueSource (we have common structures for this — including a generic dictionary version) and feed it into the binding. This makes complex property settings easily possible (e.g., MySettings.NestedObject.Name = “Test”)
Comma-Separated-Values
That’s right. Everyone’s favorite integration technique is something that’s supported OOTB in FubuCore. You can map your DTO classes using a FluentHibernate-esque column mapping and pull out your objects through the model binding subsystem to give you ultimate flexibility in your parsing.
Other examples I’ve seen
I’ve seen teams write custom rule engines that serialize data into dictionary-like formats for NoSQL storage and then pass the values back through model binding to execute the rules. I’ve also seen similar techniques used for widget-crazy-dashboards.
If you take anything away from this, let it be this
Binding classes from data is a highly useful function. A binding subsystem that is configurable and DI-enabled is invaluable. If you haven’t checked out the binding in FubuCore, then I hope this will tug at your curiosity enough to make you take a look.
Additional Resources
For further reading on how FubuCore’s model binding works and what you can do with it, I highly recommend Chad’s post: