同构(React/Redux/Express/Mongo)应用程序中的数据模型和业务逻辑

Question

我最近使用React-Redux-Express-Mongoose堆栈构建了一些isomporphic/univeral项目.

在我的猫鼬模型中包含了很多业务逻辑.作为一个非常基本的例子(借口我的ES6):

import mongoose, {Schema} from 'mongoose';

const UserSchema = new Schema({
  name: String,
  password: String,
  role: String
});

UserSchema.methods.canDoSomeBusinessLogic = function(){
  return this.name === 'Jeff';
};

UserSchema.methods.isAdmin = function(){
  return this.role === 'admin';
};

这在服务器上都很棒,但是当这些模型在浏览器中作为普通JSON对象进行水合时,我必须在一些React组件或Redux reducer中重新实现相同的业务逻辑,这对我来说感觉不是很干净.我想知道如何最好地解决这个问题.

阅读Mongoose,浏览器支持似乎有限,主要用于文档验证.我想我的主要选择是:

• 将所有业务逻辑移动到一些"普通"JS类中,并在整个地方实例化这些逻辑.例如:

  # JS Class definition - classes/user.js
  export default class User {
      constructor(data = {}){
        Object.assign(this,data);
      }
  
      canDoSomeBusinessLogic(){
        return this.name === 'Jeff';
      };
  
      isAdmin(){
        return this.role === 'admin';
      }
  }
  
  # Server - api/controllers/user.js
  import UserClass from 
  User.findById(1,function(err,user){
      let user = new UserClass(user.toJSON();
  });
  
  # Client - reducers/User.js
  export default function authReducer(state = null, action) {
    switch (action.type) {
      case GET_USER:
        return new UserClass(action.response.data);
    }
  }
  
  # Client - containers/Page.jsx
  import {connect} from 'react-redux';
  
  @connect(state => ({user: state.user}))
  export default class Page extends React.Component {
      render(){
        if(this.props.user.isAdmin()){ 
          // Some admin 
        } 
      }
  }
  

• 将所有业务逻辑移动到一些静态辅助函数中.我不会再写出整个例子,但基本上:

  # helpers/user.js
  export function isAdmin(user){
      return user.role === 'admin';
  }
  

我想上面2之间的区别只是个人偏好.但有没有人对同构应用程序和数据建模有任何其他想法？或者看过任何解决这个问题的人的开源示例.

作为上述的扩展,如何同构的save()函数,例如User.save().因此,如果在客户端上调用它,它可以对相关的API端点执行POST,如果在服务器上运行,它将调用Mongoose save()函数.

Answer 1

剧透：期待一个固执己见的答复。没有“正确”的方法来做到这一点。

首先，我想弄清楚同构和通用之间的区别，以便您确切地知道我们在说什么：

同构是在客户端和服务器端渲染之间无缝切换而不丢失状态的功能方面。通用这个术语用来强调特定的 JavaScript 代码能够在多种环境中运行。

为通用应用程序进行如此多的抽象值得吗？

一般来说，您想要一个通用应用程序是让客户端和预渲染应用程序的服务器都加载相同的代码。尽管您可以从预渲染应用程序的同一服务器运行 API，但我宁愿代理它并在不同的进程中运行它。

让我向您展示两个不同的 React 存储库：

• React + API erikras/react-redux-universal-hot-example
• React wellyshen/react-cool-starter

Erikras 著名的样板文件使用他的通用应用程序在全局共享依赖项，并在预渲染页面的服务器和客户端之间共享代码。尽管他可以，但他不分享验证。调查 API 验证 调查客户端验证

Wellyshen 没有 API，但他也共享他的依赖项和代码，尽管只是在服务器和客户端之间。服务器加载路由、存储以及客户端应用程序正在运行的所有内容。即提供同构。

话虽如此，是否将所有验证移至一处取决于您。我可能只会考虑将其用于复杂的验证案例，例如电子邮件验证，您实际上可以为此提供帮助。（这只是一个例子，对于电子邮件验证，您已经有了validator）。在某些情况下，依赖 API 验证可能会更方便，尽管这不是最佳实践。

简单的验证，就像你的例子中的验证一样，无论如何都可以使用redux-form轻松完成，我知道没有直接的方法可以在 API 上翻译它。相反，您可能应该在其上寻找快速验证器。

另一件事是，尽管一些非常流行的 React 样板将 API 和客户端结合在一起，但我倾向于使用两个不同的存储库：React + 服务器端渲染和 API。从长远来看，它将产生更清晰的代码，并且代码之间完全独立。组织大型反应应用程序