我正在构建一个简单的购物车推荐引擎。我想遵守严格的 MVC。
到目前为止，模型是：User、Items（很简单，一个user 有一个shopping cart:[] 属性，而Items 包含诸如name、@987654327 之类的信息@, brand)。
我想开始根据用户之前购买的内容向他们推荐。
到目前为止，我有以下内容：
View是API接口。
控制器与视图交互，查看输入，并为简单的 CRUD 请求获取正确的数据。
模型强制执行数据库限制，例如索引、唯一性和其他业务逻辑。
算法应该去哪里？既然它同时触及users 和items，那么将它粘在控制器中是否有意义？
【问题讨论】：
标签： node.js algorithm mongodb model-view-controller
算法应该去哪里？
它适用于什么语义概念？在这个算法执行的业务上下文中，用户在做什么？
如果用户正在查看项目集合，并且该集合用于填充相关项目的集合，那么我怀疑该算法在语义上与Item 相关联并且可以去那里。
如果用户正在查看用户个人资料或其他描述用户的内容，并且用户的信息用于推动推荐，那么成为@987654322 的一部分似乎是明智的@。
（鉴于问题中的描述，我倾向于后者。）
这真的只是一个语义问题。执行此操作时上下文中的聚合根模型是什么？执行此操作时正在查看或操作的上下文模型是什么？什么模型的信息驱动了这个操作？以此类推，以此类推。
最终，这是一个偏好问题。这取决于您决定如何对该代码中描述的业务域进行建模。而且，最重要的是，它可以改变。今天把它放在User 模型上可能有意义，明天把它放在Item 模型上可能有意义，以后为此构建一个不同的模型可能有意义。也许您开始在一个模型上执行此操作，但在实施后发现您必须跳过箍才能访问该操作，并且它确实最终在另一个模型上更有意义。所以你重构它。只要领域建模在语义上有意义，那么它就是正确的。
将其粘贴在控制器中有意义吗？
我不这么认为，不。控制器实际上是用于将用户请求路由到业务逻辑。它们不应包含业务逻辑。模型应该。 （或者模型使用的后端服务等）
【讨论】：