(I had this sitting in draft form for years now, and I just dug it up. Most of it is pretty obsolete, with .net core and all, but I’ll just leave this here.)
In a previous post, I discussed a method for using abstract classes in ASP.NET MVC 4.0. With it, I was able to clean up and hide the details of implementation from much of my code. I assumed that it would be relatively simple to do the equivalent in Web API, but I found that the task to be quite different.
The equivalent functionality requires use of asynchronous programming, code generation, and some complex processing for handling things like
Continue reading “Abstract classes as action parameters in .NET Web API 4.0″
IEnumerable. I also found some race conditions that needed to be addressed.
As a part of the API for our product, we have the need to allow the UI to send us a parcel of data, and we need to process it differently based solely on a single parameter in the data. We have decided to create an abstract model class to handle this, but MVC’s
Continue reading “Using abstract classes as controller parameters in ASP.NET MVC4″
DefaultModelBinder doesn’t work out of the box on abstract classes (or interfaces). There are many discussions out there on this, and the accepted way to solve this problem is to create a new
ModelBinder class that has more knowledge of the internals of your application than the default does. I thought about this some, and I decided to try out a few tweaks to the process.
I came upon a requirement at work to support accepting multiple ids in the Url of a “REST” request. I have no idea if this is actually considered RESTful or not, but the task was to formulate the URL like so:
The intention was to be able to retrieve multiple instances of
FooResource with one request.
So, I came up with the following MVC ActionFilter to make my life a little bit easier:
Continue reading “Accepting multiple parameters the “RESTful” way using ASP .NET Web API”
So I am having a bit of a problem here. Working on a simple library for a client to help them maintain their Active Directory entries programatically. Started with my tests. (I took this opportunity to spike Machine.Specifications, which I am finding that I quite like, but that’s for a different post.) Then researched into the APIs available from Microsoft. At first, I was quite excited about the System.DirectoryServices.AccountManagement namespace added in the 3.5 framework, until I tried to inject its classes into my own.
Now I’m running myself in circles, trying to figure out how to test my code without creating (or worse, deleting) accounts on my development box.