You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Why do Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes and ParameterBinder (and possibly others) not follow the standard interface-default implementation pattern?
#27205
The standard pattern for classes in the ASP.NET core framework is to have an interface, ISomething, that has a default implementation DefaultSomething that is registered at startup. This allows the default implementation to be swapped out as needed - either for testing, or by end-user developers.
The second part is extremely important because it allows devs to write their own implementations that merely extend the DefaultSomething implementation and call into the base class. Then the dev is able to set breakpoints in their implementation to inspect the contents of the objects being built by the default implementation, to get a better understanding of what they actually do.
A prime example of this pattern is IModelMetadataProvider and EmptyModelMetadataProvider - I simply subclassed the second and registered it in ConfigureServices and was able to see what its various methods were doing, which gave me insight to write my own ModelMetadataProvider. (No, MSDN is not enough, sometimes you just need to see the objects in the debugger.)
The current ModelAttributes and ParameterBinder classes make all of the above impossible. Not only do they not implement interfaces, they have static methods that are referenced in many places. This means that the only way to debug through these classes is to make a custom build of ASP.NET Core with Debugger.Break(); statements inserted in the appropriate locations - which is far more effort, if not downright impossible.
I'm guessing these classes are like this because they are legacy (from ye olde ASP.NET) and/or for performance reasons, but I would like to hear from the relevant ASP.NET Core devs as to the history and why these classes should stay as-is, or whether it would be appropriate to move them to the standard interface/default pattern. If the latter, I'm happy to submit PRs to cover that - they would only happen after only after 5.0 drops, though.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The standard pattern for classes in the ASP.NET core framework is to have an interface,
ISomething
, that has a default implementationDefaultSomething
that is registered at startup. This allows the default implementation to be swapped out as needed - either for testing, or by end-user developers.The second part is extremely important because it allows devs to write their own implementations that merely extend the
DefaultSomething
implementation and call into the base class. Then the dev is able to set breakpoints in their implementation to inspect the contents of the objects being built by the default implementation, to get a better understanding of what they actually do.A prime example of this pattern is
IModelMetadataProvider
andEmptyModelMetadataProvider
- I simply subclassed the second and registered it inConfigureServices
and was able to see what its various methods were doing, which gave me insight to write my ownModelMetadataProvider
. (No, MSDN is not enough, sometimes you just need to see the objects in the debugger.)The current
ModelAttributes
andParameterBinder
classes make all of the above impossible. Not only do they not implement interfaces, they have static methods that are referenced in many places. This means that the only way to debug through these classes is to make a custom build of ASP.NET Core withDebugger.Break();
statements inserted in the appropriate locations - which is far more effort, if not downright impossible.I'm guessing these classes are like this because they are legacy (from ye olde ASP.NET) and/or for performance reasons, but I would like to hear from the relevant ASP.NET Core devs as to the history and why these classes should stay as-is, or whether it would be appropriate to move them to the standard interface/default pattern. If the latter, I'm happy to submit PRs to cover that - they would only happen after only after 5.0 drops, though.
Beta Was this translation helpful? Give feedback.
All reactions