Create a common abstraction for Application/Action/Controller -Models

[Grinderofl]

Currently in MVC there exists 3 types of application models:
ApplicationModel, ControllerModel, ActionModel

All of the models share some common properties, like ApiExplorer, Filters, and Properties. I would like for the models to inherit from a ModelBase that has ApiExplorer, Filters and Properties as base. This would facilitate support for creating generic conventions that wouldn't necessarily have to apply to one specific model type.

Sample use case:
I have added the functionality to MVC to register filters programmatically without using attributes, via fluent interface. To achieve this functionality, I have a generic base FilterModelConvention, with three methods:
public void Apply(TModel model)
protected abstract IEnumerable<IFilterRegistration> CreateRegistrations(TModel model);
protected abstract Func<TModel, IList<IFilterMetadata>> CollectionPropertySelector()

In the end, the Apply method does this:
CollectionPropertySelector()(model).Add(filter);

I would much rather be able to specify TModel as a generic type ModelConvention, and have in Apply

model.Filters.Add(filter);

Resolving these sorts of problems is tricky, as first one has to figure out the smallest common denominator to start building up from - more difficult for those that don't use the more complex language features on a daily basis. Having an abstract base that has at least the most basic properties makes a good starting point, and looking at codebase I can't find any immediate pitfalls to this approach - however would make developers' lives better (by keeping us sane by not forcing us to fall back on reflection or write same code three times...).

If this is something that you would consider having in there, but is not in the team's sights for near future, I'm willing to implement and PR, as the parallel development of our internal kit could make huge use of this approach.

[danroth27]

@rynowak

[rynowak]

I really like the idea of this.

Having an abstract base that has at least the most basic properties makes a good starting point, and looking at codebase I can't find any immediate pitfalls to this approach - however would make developers' lives better (by keeping us sane by not forcing us to fall back on reflection or write same code three times...).

Agreed. I considered briefly adding a feature/facet paradigm to solve this, but it seems like overengineering. I think starting with the abc is the right thing to do.

Would like to come up with a slightly better name than ModelBase as PropertyModel and ParameterModel don't overlap with this. Don't block on the name for now, I'll try to brainstorm something better.

Please go ahead and send a PR - ideally this week as we're locking for beta8 on Friday. I'd love to see some examples of what you're using this for when you're done.

[Grinderofl]

A PR has been submitted, I've opted for interfaces over superclass, as it gives slightly better granularity of control, and includes support for PropertyModel and ParameterModel.

Hoping to get our kit pushed to open source so I could share the codebase that we would use this for. Big kudos for implementing the builder pattern, btw.

[rynowak]

49acfd5