After peaking my interest that ASP.NET vNext can run on Linux and Mac via mono. I decided to spend a little time to see what else has changed.
One of my favorite aspects of working with FubuMVC was the POCO-style controllers that removed a lot of the cruft of framework and cross-cutting concerns out of your controllers.
Why are POCO controllers good?
It’s a fair question and the answer isn’t black and white. If I’m writing code that matches the standard way in which view location is wired up 90% of the time. I can probably lean on that a bit and reduce the repetition and noise inside my controller and make something that does this for me. However, just removing the base-class doesn’t quite get us to where we need to be to reduce this repetition. Ideally, we would also want to return a simple POCO model as well and have something later in the pipeline do the repetitive stuff for us. This would also have the added benefit of making tests easier to write because you wouldn’t ever have to wire up any framework goop to get things going.
Is this just another post on the same topic I’ve already seen?
This isn’t the first time someone has mentioned the ability to do this, so how is the fubu-style different? To my point earlier, injecting things like ViewDataDictionary and returning an IActionResult isn’t really reducing the framework friction. However, MVC now has an interface called IOutputFormatter that is there to support content negotiation. This is how fubu’s view engine worked under the covers. In the same way that you output serialized JSON when the accepts header uses “application/json”. You can also choose to render HTML when the accepts header is “text/html”.
Controllers the “fubu” way
I started with the yeoman generator template that gives you the almost standard ASP.NET MVC bootstrap start page. I mentioned I’m running on a Mac right? This approach will work with Windows and Visual Studio as well. I’ve adapted the yeoman generated application in my sample to look like the following.
Now if you browse to the home route you’ll likely see XML rendered to the screen instead of the view. Let’s fix that. First let’s setup something that can render a view for content negotiation.
Last we’ll wire up our new output formatter in Startup.cs
Now if you refresh the page you should see the same html output you started with, but without the repetition and framework code in your controller.
I’m interested to see if others find this approach useful. Would you find value in this? Or are you more happy to be explicit regardless of repetition?