> Missed this before... We've gone to quite some lengths to make this pattern not required.

I know. You don't have to use this pattern as long as you know how to get hold of your `app` object in different means.

> This makes models useful only if an app is available... I'm not entirely against this, but would like to justify the added constraint.

We want to get rid of global static model/datasource registries at some point in the future and provide containers (scopes) in which models are registered. An example of such container is a loopback app object. We have the container semantics partially implemented via `app.models` and  `app.datasources`.

That means you can't define a new model by calling the global static `Model.extend` anymore, you need a reference to the container.

So far we recommended `require('../app.js')`. That works in the old server-side-only project layout, but does not work for isomorphic code - the app object is created in multiple places depending on whether you are running in a browser or on the server.

The pattern `module.exports = function(dependencies...)` seems like the cleanest solution to me.

----

On the second thought, since loopback is still maintaining a static global registry, the code can get the model from that registry without requiring the app object:

```js
var Todo = loopback.getModel('Todo');
```

Such approach won't work for `boot/*` scripts though. We could implement an `app` singleton accessible via `loopback.getApp()` to "fix that".

Anyways. IMO the dependency injection is the direction we want to go in the future, thus I'd rather teach people this new approach.