WebApi create and EF Inheritance - entity-framework

Question

I have following entities:
abstract class User
{
string Id
string Name
}
class UserA: User
{
string PropA
}
class UserB : User
{
string PropB
}
It is a good solution to have a unique create (post) with a dynamic parameter and instantiate the subclasses according to a property?
[HttpPost]
public IActionResult Create([FromBody]dynamic data)
{
if (data.PROP == null)
{
_context.Users.Add(new UserA(data.PropA));
}
else
{
_context.Users.Add(new UserB(data.PropB));
}
...

Answer 1

Don't use dynamic. I'm actually kind of surprised that works at all. Though there's no indication that you've actually tested this code yet, so perhaps it doesn't. The modelbinder needs to know a concrete type to bind to, so that it can determine how to map the values onto the destination instance. Without strong types, it can't do anything but make everything a string, since that is how it comes in the request body.
Anyways, for something like this, the correct approach is to use a view model. Your view model should contain all the properties for all the various possible derived types. Again, the modelbinder needs these to determine how to map the data from the request body over, so if a property doesn't exist, it will simply discard the associated data.
This is also why you cannot simply use the base class. If this were a normal method, you could do something like:
public IActionResult Create([FromBody]User data)
Then, inside, you could use pattern matching or similar to cast to the correct derived type. This works because ultimately, the object in memory would actually be an instance of something like UserA, and you're simply up-casting it to User. As a result, you can always cast it back to UserA. However, actions are different. What's coming in from the request is not an object instance. The modelbinder serves to create an object instance out of it, by inspecting the parameter it needs to bind to. If that parameter is of type User, then it will fill the properties on User, and discard everything else. As a result, the object in memory is just User, and there's no way to cast to something like UserA - at least in terms of having all the values that were actually posted for an instance of UserA being on the object.
Which brings us back to the view model:
public class UserViewModel
{
public string Id { get; set; }
public string Name { get; set; }
public string PropA { get; set; }
public string PropB { get; set; }
}
Then, have your action accept that as a param:
public IActionResult Create([FromBody]UserViewModel data)
Then, inside:
if (!string.IsNullOrWhiteSpace(data.PropA))
{
// UserA was posted, map data to an instance of UserA
}
Similarly for UserB. If you like, you could also post an explicit "type" along with the data and switch on that to instantiate the right type. It's up to you. To reduce code duplication, you can instantiate the right type, but store it in an variable of type User. Then, if you need to get back at the correct type, you can use pattern matching:
User user;
switch (data.Type)
{
case "UserA":
user = new UserA
{
Id = data.Id,
Name = data.Name,
PropA = data.PropA
};
break;
// etc.
default:
user = new User
{
Id = data.Id,
Name = data.Name
};
break;
}
Then later:
switch (user)
{
case UserA userA:
// do something specific with `userA`
// etc.
}
Or:
if (user is UserA userA)
{
// do something with `userA`
}