feat(core): add sugar function for model binding

[shimks]

Description

Adding in sugar function for ctx.bind('model.modelName').toClass(modelCtor).tag('model'). This is done as a part of #786 and #441. In order for metadata for the models to be accessed, users require access to the names of the models, which in turn can be provided by using these bindings.

Checklist

• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide

[shimks]

@slnode test please

[raymondfeng]

Based on #742, should we remove options.models support?

[shimks]

ah yes, i wrote this before the discussion. I'll get rid of this option

[bajtos]

The code changes look reasonably to me, but I am not sure what is the value of these bindings? So far, our Best Practices don't register models for dependency injection because models and repositories are pretty tightly coupled together.

How do you envision that this model registry will be used in applications? What will the new best practices look like? What kind of changes will be needed in https://github.com/strongloop/loopback4-example-getting-started?

[shimks]

@bajtos I'm currently working on #786 which would leverage the @model and @property decorators to build JSON schemas from their metadata. My approach was to register these models with dependency injection at boot in order to get their constructors to use as keys to access the metadata.

Essentially, there would be no changes required in any of the examples (or our best practices) since these are intended to be used at boot as sugar. On second thought, once #786 is done we could think about changing our Best Practices section to reflect some of the changes made. An example might be to drop type as a key to pass in for @property, since our metadata is able to find that out itself.

[bajtos]

@shimks

I'm currently working on #786 which would leverage the @model and @Property decorators to build JSON schemas from their metadata. My approach was to register these models with dependency injection at boot in order to get their constructors to use as keys to access the metadata.

I am afraid I still don't understand. Could you please point me to the code where demonstrating this approach? Is it necessary to register those models with DI, cannot we use an approach that's closer to our current Best Practices?

On second thought, once #786 is done we could think about changing our Best Practices section to reflect some of the changes made. An example might be to drop type as a key to pass in for @Property, since our metadata is able to find that out itself.

+1 for dropping type from @property annotations in our Best Practices code examples.

[shimks]

@bajtos Looks like I had a couple of misunderstandings of what #786 entailed. This PR is no longer useful to the aforementioned PR and I'd be ok with closing it

[bajtos]

This PR is no longer useful to the aforementioned PR and I'd be ok with closing it

Ok, let's close it then.