Naming convention of things about dendritic

[davidbanham]

For avoidance of doubt, any time I use a word below I'm referring to its meaning under the proposed New World Order :)

What's the value proposition in adding another layer? What's the benefit of having a Controller, Model and Schema? What responsibility would the Model hold that the Controller and Schema wouldn't?

Or, perhaps a better question, what responsibility would the Route hold that the Controller wouldn't?

[Nicktho]

What responsibility would the Model hold that the Controller and Schema wouldn't?

Model would have your findAll, create, update methods using the database library. Schema would just be the json schema. Controller would take your req and res, call the model functions and pass it to res.send.

what responsibility would the Route hold that the Controller wouldn't?

The route would just be a mapping of a string representation of a route, and the controller action to call, eg:

{ route: '/todos/:todoId', action: todoController.create }

There is no real extra layer here, besides importing an action instead of using an anonymous function, it's more just a shift of naming to more closely reflect rails.

Route is a definition, controller handles the request, model is responsible for retrieving and updating data.

[Nicktho]

The value in the change is to reflect current naming conventions in these types of applications, so that we reduce confusion when talking about concepts and help involve a wider community that may be moving from platforms with the current naming conventions.

[davidbanham]

Cool. I think that's probably a reasonable way to go. Next step I think is a PR. That way we can look at the implications of the change, decide how it feels, and merge if we're happy. No need to ensure the PR is the most polished perfect thing it can be. Let's get something quick together, validate the direction, then polish it up before merging assuming that we like it.

[nwinch]

Related #40

[MadRabbit]

Oh, cool, you have this discussion already. I've touched a bit my thoughts on this in #40, but a few more words. @Nicktho is generally right, I +1 his definition of a model and a schema. A model is basically a type or a value object that conforms with a schema.

One thing though. I'd steer away from controller, this causes confusion in teams all the time, because routes in nodejs apps basically play the role of a controller in your everyday MVC structure. Some projects, like rails for example, split routes and controllers, but their routes is just a dumb config. it doesn't really have much logic. In case of expressjs and similar, your routes basically play the role of what's called the front controller.

Basically a router in node should be an equivalent of a shallow controller. That router-controller thing is supposed to talk to either a Model (if it is a simple case) or a business logic thing. That businesslogic thing is often called services (to avoid confusion with controllers).

Business logic is basically the smarts around the model. It does data transformation and such, but it is completely gnostic from the use case. Busniess logic should now know anything about the HTTP server. It shouldn't care about query params, forms and such. It just deals with data.

So, in this light what works and scales well is a split that looks so:

routes/ <- deal with the HTTP requests and call models or services
services/ <- contains the business logic, can be missing in simple CRUD apps
models/ <- value objects or records that represent the db schema

Also, in the context of a nodejs app, it is worth having a separate folder called middleware, that is where
your reuseable data transformation things go, like authenticate, authorize, findThing, logActions, etc.

As for schema it is heavily depend on a specific ORM implementation. In most cases the schema is defined within the models definitions. As for connection details, json schema constraints and such, that should go into a config/ folder.

That is pretty much a structure and naming convention that repeats itself in many projects and the one that scales well from a small project to a pretty large monolith.

[MadRabbit]

any feedback on this? @davidbanham @nwinch @Nicktho

[nwinch]

This can be tagged as "todo" I believe, as everyone seems to generally agree with the direction outlined by @Nicktho, and then also furthered by @MadRabbit.