MVC in node and in general: how are models attached to views?

Question

I start with node.js and create a simple MVC framework. For now, I have a front controller (or "dispatcher" if you want). Routing is done through the dispatcher configuration module, as shown.

My questions are at the end, right after the code. In addition, this is an exercise in learning node, please do not offer express.js and the ones you like.

dispatcherConfig.js

var url = require('url'); (function() { var dispatcherConfig = { '/' : 'homeController', '/index.html' : 'homeController', '/sayHello.html' : 'helloController', '404' : '404Controller' }; module.exports.getController = function(request) { var route = url.parse(request.url, true).pathname; if(dispatcherConfig[route]) { return dispatcherConfig[route]; } return dispatcherConfig['404']; } }()); 

This is used by dispatcher.js :

 var dispatcherConfig = require('./config/dispatcherConfig'); (function() { module.exports.dispatch = function(request, response) { var requiredController = dispatcherConfig.getController(request); var controller = require('./controllers/' + requiredController); controller.doService(request, response); } }()); 

And here is what the controller example looks like (dandy also works) - homeController.js :
(Please ignore inline view code)

 (function() { var homeController = { doService: function(request, response) { response.write('<form action="/sayHello.html" method="GET">' + '<input id="name" name="name" size="20" />' + '<input type="submit" value="Submit" />' + '</form>'); } } module.exports.doService = function(request, response) { return homeController.doService(request, response); } }()); 

This routing works well. I have controllers that easily connect to url patterns, and I emulate the type of the multi-adapter type spring, and then inspect the request object.

Three obvious things to do here:

• Creating view objects
• Creating Model Objects
• Designations and binding models

---

Questions

• In MVC (spring at least), these are controllers that associate a view with a model. Is this the best way to do this? What if I maintain a separate separate configuration that describes which view is associated with that model, and the controller only goes to the view. Is it wrong and not MVC?
  
  
• What is a good way to represent a view in node.js? Since it is heavily template-based, what template options are offered (matured)?
  
  
• If I load a static file (say, a CSS file loaded by reading the file into memory) and I keep a link to the contents in the global area / application, then subsequent requests can be served directly from memory, which led to phenomenal speeds, is the assumption true? In fact, we can guarantee that after the first request to enter the node server (which will cause the file to be read and the contents are loaded into memory), all subsequent requests will be served from memory (for such static content).
  
  
• What is the low level (no frame) for capturing POST data in raw node.js?

Thanks.

Answer 1

To answer your question with a headline, here is how I explained it to me:

A controller is a router, it accepts incoming requests, connects them to some business logic (including data fetching) and some rendering method, and then spits them back into the queue. Think of it as a mail sorter or something else: "Here is the address, there is garbage."

Submission should be dumb. He should take the data and enter it into the slots and, possibly, do some cycles for the tables and, possibly, include some other kinds, but about that. Render HTML. Even better is a "view" that "displays" XML or JSON output or simply raw data back to the client. (all types)

The model is the hard part because where you process the data coming into the system, or the results coming from the database. Thus, there can be many “layers”, and you can make many nested calls. Here you will check the input that goes beyond the scope of the health check (and return the corresponding carrier messages to the controller in case of failures), this is where you are going to pre-process before storage and perform the post-process that left the database. This is where logic lives.

Here's the thing: We are no longer doing anything monolithically, we call what we intend to accomplish. Thus, by invoking a specific controller, you have definitely set some information semantically (see Why they call it a semantic network because of this).

Thus, we can allow ourselves to make the controller more stupid (the caller knows the intent). We can afford to make the model more obtuse (it processes a certain bit of business logic and storage for the controller). And the look was always dull.

Not to say that one class of the model cannot be large enough. But the part that a separate controller must call must be narrow.

For other requests:

In MVC (spring at least), these are the controllers that bind the view to the model. Is this the best way to do this? What if I support a separate separate configuration that describes which view is attached to which model, and the controller only directs to the view. Is it wrong, not MVC?

See above, I think I already reviewed this. The controller is invited to do a certain thing based on what you semantically want. The controller is not an expression of monolithic switching, so there is no need for it to have a lot of configuration.

What is a good way to represent a view in node.js? Since it is heavily template-based, what template options are offered (matured)?

"represents the view"? Um, browse engines make a match on their own. Are you sure you want to write your own view engine? It can be done. Toxicize the view file, find the "control verbs" (due to the lack of a better name, I'm sure they are), insert the data there, then draw the entire marker structure as a string (HTML is essentially a string, no?). That’s all I have in a nutshell. My advice: let people see the work in the view, you do not need to rewrite them all.

If I load a file that needs to be statically set (say, a CSS file loaded through a file read into memory) and I keep a link to the contents in the global / application area, then subsequent requests can be served directly from memory, which leads to phenomenal speeds Is this assumption correct? In fact, we can guarantee that after the first request entering the node server (which will start reading the file and the loaded content into memory), all subsequent requests will be served from memory (for such static content).

This is a correct guess. This is what I would do with a regular garbage collection program to check every few minutes and destroy any file older than n minutes, and then reload subsequent requests, ensuring that you get relatively recent files. But this is really what caching proxies do, so yes, that’s perfectly acceptable.

What is the low level (no frame) for capturing POST data in raw node.js?

Not. node does this for you. It is already represented in the request object.

Answer 2

The most commonly used template modules I've seen with node are Jade and EJS, mainly because Express has built-in support for them. If you are not going to use Express, I will also seriously look at Mustache (I personally prefer my Jade / EJS philosophy).