Consider creating abstractions package

[stevendarby]

If you like to have your models in a separate library that doesn't have references to framework specific packages like ASP.NET Core, MVC etc. then this is undermined if you want to apply HybridBindProperty attributes to their properties, as the dependencies of your package include ASP.NET Core packages. This could be avoided with a separate package for just abstractions/attributes. Arguably the naming of these attributes and their arguments somewhat undermines the abstraction of the models anyway, but at least without the additional packages.

Just something to consider! :)

[billbogaiv]

Seems like a reasonable use-case. I'll probably call the package HybridModelBinding.Core. I'm working to push a 1.0-release and can plan to tie this issue to that release.

[stevendarby]

I’ve actually changed my mind on this! But of course feel free to do what you think is best. I’ll explain why I changed my mind.

Previously I was thinking of attributes like Required, MaxLength etc. that MS abstracted into the ComponentModel package. These are then used by certain frameworks, like MVC for validation in the controller and entity framework for modelling the database.

However, their FromBody etc. attributes are in MVC and I think that’s probably fair enough as their meaning can’t really be abstracted from MVC.

In the use-case I described, the ‘proper’ thing for me to do is probably have an interface/base class in a shared abstract library and then implement/override the properties in the MVC project to apply the Hybrid attributes to them.