-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Create a common abstraction for Application/Action/Controller -Models #3158
Comments
I really like the idea of this.
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 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. |
A PR has been submitted, I've opted for interfaces over superclass, as it gives slightly better granularity of control, and includes support for 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. |
Currently in MVC there exists 3 types of application models:
ApplicationModel
,ControllerModel
,ActionModel
All of the models share some common properties, like
ApiExplorer
,Filters
, andProperties
. I would like for the models to inherit from aModelBase
that hasApiExplorer
,Filters
andProperties
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 inApply
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.
The text was updated successfully, but these errors were encountered: