节点和通用中的MVC：模型如何与视图相关联？ [英] MVC in node and general: How are models tied to views?

问题描述

我从node.js开始，我正在创建一个简单的MVC框架。到目前为止，我有一个前端控制器（或调度员，如果你愿意的话）工作。路由通过调度程序配置模块进行，如图所示。

I'm starting with node.js and am making a simple MVC framework. So far, I've got a front controller (or 'dispatcher', if you will) working. The routing happens through a dispatcher config module, as shown.

我的问题在代码之后的最后。此外，这是学习节点的练习，请不要建议express.js等。

My questions are at the end, immediately after the code. Also, this is an exercise in learning to node, please do not suggest express.js and the likes.

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'];
    }
}());

这是由 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);
    }
}());

以下是样本控制器的样子（也适用于花花公子） - homeController.js ：

（请暂时忽略内联视图代码）

And here is what a sample controller looks like (works dandy too) - homeController.js:
(Please ignore the inline view code for now)

(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);
    }
}());

此路由工作正常。我已经让控制器很容易连接到url模式，并通过进一步检查请求对象来模拟spring的多操作控制器类型。

This routing works nicely. I've got controllers easily wiring up to url patterns, and am emulating spring's multiaction controller type as well, by further inspecting the request object.

需要的三个显而易见的事情这里完成的是：

Three obvious things that need to be done here are:

1. 创建视图对象


2. 创建模型对象


3. 绑定视图和模型

---

问题：

1. 在MVC（至少是春天）中，它是用
   模型绑定视图的控制器。这是最好的方式吗？如果我将单独的
   单独配置来描述哪个视图绑定到
   模型，并且控制器仅路由到视图，该怎么办？这是错误的吗？
   不是MVC吗？
   
   


2. 在node.js中表示视图的好方法是什么？由于它是基于模板的
   ，所提供的模板选项是
   （成熟的）？
   
   


3. 如果我加载文件是静态服务（比如CSS文件，通过文件读入内存加载
   ），并且我在全局/应用范围内保留对
   内容的引用，然后后续请求可以是
   直接从记忆，导致惊人的速度，这个
   假设是正确的吗？事实上，我们可以保证在第一个
   请求进入节点服务器之后（这将触发文件读取
   并且内容被加载到mem），所有后续请求
   将从内存（对​​于这样的静态内容）。
   
   


4. 在
   raw node.js中获取POST数据的低级（无框架）方法是什么？

1. In MVC (spring at least), it's controllers that bind a view with a model. Is this the best way of doing it? What if I maintain separate a separate configuration which describes what view binds to what model, and the controller only routes to a view. Is this wrong and not MVC?
   
   
2. What is a good way to represent a view in node.js? Since it is heavily template based, what templating options are on offer (matured ones)?
   
   
3. If I load a file to be served statically (say CSS file, loaded through file read into memory), and I keep a reference to the contents in the global/app scope, then subsequent requests can be served directly from memory, resulting in phenomenal speeds, is this assumption correct? In fact, we can guarantee that after the first request entering the node server (which will trigger the file read and the contents being loaded into mem), all subsequent requests will be served from memory (for such static content).
   
   
4. What is the low level (framework-less) way of grabbing POST data in raw node.js?

谢谢。

推荐答案

要回答你的标题问题，这就是我向它解释的方式：

控制器是路由器，它接收传入请求，将它们与一些业务逻辑配对（包括获取数据）和一些渲染方法，然后将它们从队列中吐出。可以把它想象成一个邮件分拣机或者其他东西：这是一个地址，有一个垃圾箱。

To answer your title question, this is how I had it explained to me:

The controller is the router, it takes incoming requests, pairs them up with some business logic (that includes fetching data), and some rendering method, and then spits them back out the queue. Think of it as a mail sorter or something: "Here's an address, there's a bin".

该视图应该是愚蠢的。它应该采用数据并将其填充到插槽中，并且可能为表执行一些循环，并且可能包含一些其他视图，但这就是它。渲染HTML。更好的是渲染XML或JSON输出的视图，或者只是原始数据返回给客户端。 （所有观点）

The view is supposed to be dumb. It's supposed to take data and stuff it into slots and maybe do some loops for tables, and maybe include some other views, but that's about it. Render HTML. Even better is the "view" that "renders" XML or JSON output, or just raw data back to the client. (all views)

模型是棘手的部分，因为这是您处理数据的地方，或来自数据库的结果。所以这里可能有很多层，你实际上可能会做很多嵌套调用。在这里，您将验证超出完整性检查的输入（并在故障时将适当的载体消息返回到控制器），这是您在存储之前预处理的地方，并对数据库中的内容进行后处理。这就是逻辑存在的地方。

The Model is the tricky part, because that's where you process data coming in, or results coming from the database. So there may be many "layers" here, and you may actually make many nested calls. This is where you're going to validate inputs beyond sanity checks (and return appropriate carrier messages back up to the controller on failures), this is where you're going to preprocess before storage, and postprocess what came out of the database. This is where the logic lives.

事情就是这样：我们不再单一地做事了，我们正在呼唤我们打算发生的事情。所以通过调用一个特定的控制器，你已经在语义上指定了一些信息（看看为什么他们称之为语义网，因为这个）。

Here's the thing: We're not doing things monolithically anymore, we're calling what we intend to have happen. So by calling a specific controller, you've already specified some information, semantically (see why they call it the semantic web, because of this).

所以我们买得起使控制器dumber（调用者知道意图）。我们可以负担得起模型数量（它为控制器处理特定的业务逻辑和存储）。并且视图总是愚蠢的。

So we can afford to make the controller dumber (the caller knows the intent). We can afford to make the model dumber (it's handling a specific bit of business logic and storage for the controller). And the view was always dumb.

这并不是说单个模型类不能很大。但是单个控制器应该调用的部分应该是窄的。

That's not to say that a single model class can't be quite large. But the part that the individual controller should call should be narrow.

在MVC（至少是spring）中，它是将视图与模型绑定的控制器。这是最好的方式吗？如果我单独配置一个单独的配置，该配置描述哪个视图绑定到哪个模型，并且控制器仅路由到视图，该怎么办？这是错误的而不是MVC吗？

In MVC (spring at least), it's controllers that bind a view with a model. Is this the best way of doing it? What if I maintain separate a separate configuration which describes what view binds to what model, and the controller only routes to a view. Is this wrong and not MVC?

见上文，我想我已经涵盖了这一点。要求控制器根据您的语义需要做某件事。控制器不是单片开关语句，因此不需要在其中进行大量配置。

See above, I think I already covered this. A controller is requested to do a certain thing based on what you semantically want. A controller is not a monolithic switch statement, so there's no need to have lots of configuration happening therein.

什么是表示的好方法node.js中的视图？由于它是基于模板的，提供了哪些模板选项（成熟的）？

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

代表视图？嗯，查看引擎自己进行匹配。你真的想写自己的视图引擎吗？可以办到。对视图文件进行标记，找到控制动词（缺少更好的名称，我确定它们有一个），在那里插入数据，然后将整个标记化结构渲染为字符串（HTML本身就是一个字符串，没有？）。这就是我得到的所有内容。我的建议是，让查看人员进行查看工作，你不需要全部重写。

"represent a view"? Um, view engines do the matching up on their own. Do you really want to write your own view engine? It can be done. Tokenize a viewfile, find the "control verbs" (for lack of a better name, I'm sure they have one), insert data there, then render the entire tokenized structure back out as a string (HTML is inherently a string, no?). That's all I got for a nutshell. My advice is, let the view people do the view work, you don't need to rewrite them all.

如果我加载文件静态服务（比如CSS文件，通过文件读入内存加载），我保留对global / app范围内容的引用，然后后续请求可以直接从内存中提供，产生惊人的速度，这是假设正确？事实上，我们可以保证在第一个请求进入节点服务器后（它将触发文件读取并将内容加载到mem中），所有后续请求将从内存中提供（对于此类静态内容）。

If I load a file to be served statically (say CSS file, loaded through file read into memory), and I keep a reference to the contents in the global/app scope, then subsequent requests can be served directly from memory, resulting in phenomenal speeds, is this assumption correct? In fact, we can guarantee that after the first request entering the node server (which will trigger the file read and the contents being loaded into mem), all subsequent requests will be served from memory (for such static content).

这是一个正确的假设。这就是我要做的事情，使用一般的垃圾收集例程来检查每隔几分钟并粉碎任何超过n分钟的文件，然后重新加载后续请求，确保您获得相对较新的文件。但这实际上是缓存代理所做的，所以是的，这是完全可以接受的。

That is a correct assumption. That is what I would do, with a general garbage collection routine to check every few minutes and shred any file older than n minutes, and then reload on subsequent requests, ensuring that you're getting relatively recent files. But this is effectively what caching proxies do, so yes, that's perfectly acceptable.

什么是低层（无框架）方式抓取raw node.js中的POST数据？

What is the low level (framework-less) way of grabbing POST data in raw node.js?

你没有。 Node为您完成此操作。它已经在请求对象中显示。

You don't. Node does this for you. It's presented in the request object already.

这篇关于节点和通用中的MVC：模型如何与视图相关联？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！