前端和后端目录说明

1. 文件夹和文件夹内部文件的语义一致性

模块文件夹应该保证单一入口和出口，怎么理解呢。

project
|-- src
    |-- components
        |-- input
            |-- index.js
            |-- index.module.scss
    |-- pages
        |-- seller
            |-- components
                |-- input
                    |-- index.js
                    |-- index.module.scss
            |-- reducer.js
            |-- saga.js
            |-- index.js
            |-- index.module.scss
        |-- buyer
            |-- index.js
        |-- index.js

一般来说我们的目录结构都会有一个文件夹是按照路由模块来划分的，这个文件夹一般叫 pages 或者是 routes。这个文件夹里面应该包含我们项目所有的路由模块（上面的例子路由模块指的是 seller 和 buyer），并且仅应该包含路由模块，而不应该有别的其他的非路由模块的文件夹。

这样做的好处在于一眼从 pages 文件夹看出这个项目的路由，比如上面的例子我们就可以说有 /seller 和/buyer 两个路由，如果混入了其他非路由的文件夹就会混淆这里面都是路由文件夹的约定。

2. 单一入口/出口

接着上面的例子来讲，seller 文件夹应该作为一个独立的模块由外部引入，并且 seller/index.js 应该作为外部引入 seller 模块的唯一入口。换句话说，假如我有个 rootReducer 要引入 seller 的 reducer，我应该从 seller/index.js 文件引入，而不应该直接从 seller/reducer.js 引入。因为外部不应该知晓路由文件夹内部的文件分布，而是应该全部从 index.js 导入。同时 seller 内部文件不管如何分布，需要外部引入的都要在入口文件 index.js 导出。

// rootReducer.js
// 错误用法
import sellerReducer from 'src/pages/seller/reducer'

// 正确用法
import { reducer as sellerReducer } from 'src/pages/seller'

// seller/index.js
// 同时
import reducer from './reducer'
export {
    reducer
}

这样做的好处在于，无论你的模块文件夹内部有多乱，外部引用的时候，都是从一个入口文件引入，这样就很好的实现了隔离，如果后续有重构需求，你就会发现这种方式的优点

3. 就近原则，紧耦合的文件应该放到一起，且应以相对路径引用

继续使用上面的例子，在 seller/index.js 中使用样式，一般我们会用相对路径的方式。这里为什么不用绝对路径，可能有人说是写起来方便，但是实际上这里用相对路径可以保证这个 seller 模块内部的独立性。

// seller/index.js
// 正确用法
import styles from './index.module.scss'
// 错误用法
import styles from 'src/pages/seller/index.module.scss'

怎样理解？我们现在的 seller 目录是在 src/pages/seller，如果我们后续发生了路由变更，需要加一个层级，变成 src/pages/user/seller。如果我们采用第一种相对路径的方式，那就可以直接将整个文件夹拖过去就好，seller 文件夹内部不需要做任何变更。但是如果我们采用第二种绝对路径的方式，移动文件夹的同时，还需要对每个 import 的路径做修改。

这样做的好处？就是上面说的。

4. 公共的文件应该以绝对路径的方式从根目录引用

公共指的是多个路由模块共用，上面的 src/components/input 就是一个公共组件。如果我们要在 buyer 模块使用这个组件可能有下面两种引用方式

// buyer/index.js
// 错误用法
import Input from '../../components/input'
// 正确用法
import Input from 'src/components/input'

为什么？和上面的原因一样，如果我们需要对文件夹结构进行调整。将 /src/components/input 变成 /src/components/new/input，如果使用绝对路径，只需要全局搜索替换。而如果使用相对路径，则需要一个个找，很麻烦。

其实方便文件夹结构调整是次要的，主要的原因还是绝对路径有全局的语义，相对路径有独立模块的语义。这点会方便新上手的人熟悉这个模块是共用的还是私有的。

5. /src 外的文件不应该被引入

这一点就比较好理解了，而且其实已经有脚手架做了相关的约束了，正常我们的前端项目都会有个 src 文件夹，里面放着所有的项目需要的资源，js, css, png, svg 等等。src 外会放一些项目配置，依赖，环境等文件。所以，src 文件夹外不应该放需要被引入的资源。

这样的好处是方便划分项目代码文件和配置文件

总结

项目的目录结构很重要，因为目录结构能体现很多东西，怎么规划目录结构可能每个人有自己的理解。但是上面这些原则是我个人觉得是比较通用的，如果一个项目能遵循上面的原则，至少可以说，不会乱。

这里有两个点我觉得是需要拎出来再强调一遍的：

一个是约定带来的语义，上面的 5 点都体现了这点，约定带来的语义可以很大程度减少我们理解项目的时间和难度
另一个就是面向重构编程，其实无论是使用 TypeScript 还是像上面的 3，4点一样约定对模块文件和公用文件的引用方式，都是为了在项目结构调整或者重构的时候，更快更安全的对文件进行修改。一个成熟的长期维护的项目，是一定要把重构的坑埋到代码里面的。

后端服务器的组成： pom.xml（Maven项目配置文件） + java文件夹 + resource文件夹

代码层（java）,根目录com.xxx： XxxApplication.java + 对应模块代码（domain + controller + service + mapper等）

XxxApplication.java（项目主入口，main方法）
controller: 控制层，请求接口
service: 服务层，逻辑代码, 数据服务的实现接口(serviceImpl)UserService.java 和 UserServiceImpl.java
mapper: 数据层，或者dao，比如UserMapper.java 、UserMapper.xml
domain: 实体类，同 bean、entity、model

　　bean：任何一个java类都可以成为一个bean，这个类里包含对象的属性、get、set方法及其他的业务逻辑。

　　model： model是MVC中的概念，可以理解为View层展示数据的对象。

　　entity:数据表对应到实体类的映射。

资源层（resource）：存放资源文件，比如邮件html、mapper

email邮件模板，比如registerSuccess.html
properties配置文件，比如mybatis.properties
mapper文件，比如UserMapper.xml（也可以写到代码层的mapper文件夹中）
template模板
application.yml
log4j2.xml日志配置

// 根目录结构
-src: 
　　-main: 
　　　　-java: - com.xxx
　　　　-resource: -
　　-test: 
-target:
-pom.xml

src/main/java：代码文件目录
src/main/resource：资源文件目录
pom.xm：Maven项目配置文件

// java代码文件目录： 文件目录按如下进行规范命名
-java:
    -com.xxx:
        -entity
        -controller
        -service
        -mapper
        -util
        -XxxApplication.java

entity：实体类，也可以命名为bean、entity、model，例如User.java
controller：控制层，请求接口，例如UserController.java
service：服务层，以及关联的接口文件，例如UserService.java（impl/UserServiceImpl.java）
mapper：数据层，也可以命名为dao，例如UserMapper.java和UserMapper.xml
model: 请求使用到的实体类： xxxRequestTO.java、xxxReponseTO.java
config、constant、util等配置文件
XxxApplication.java ：项目主入口，main方法

// resource资源文件目录
-resource: 
    -mapper
    -static
    -template
    -application.yml

application.yml：配置文件，也可命名为application.properties

// 数据库配置 -- application.yml
spring:
    datosource:
        driver-class-name: com.mysql.cj.jdbc.Driver
        url: jdbc:mysql://localhost:3306/dataBaseName?userUnicode=true&characterEncoding=utf8&serverTimezone=GMT%2B8
        username: youMysqlUsername
        password: yourMysqlPassword

















vue架构

vue项目目录结构详解

项目简介
基于 vue.js 的前端开发环境，用于前后端分离后的单页应用开发，可以在开发时使用 ES Next、scss 等最新语言特性。项目包含：

基础库: vue.js、vue-router、vuex、whatwg-fetch
编译/打包工具：webpack、babel、node-sass
单元测试工具：karma、mocha、sinon-chai
本地服务器：express
目录结构

├── README.md 项目介绍

├── index.html 入口页面

├── build 构建脚本目录

│ ├── build-server.js 运行本地构建服务器，可以访问构建后的页面

│ ├── build.js 生产环境构建脚本

│ ├── dev-client.js 开发服务器热重载脚本，主要用来实现开发阶段的页面自动刷新

│ ├── dev-server.js 运行本地开发服务器

│ ├── utils.js 构建相关工具方法

│ ├── webpack.base.conf.js wabpack基础配置

│ ├── webpack.dev.conf.js wabpack开发环境配置

│ └── webpack.prod.conf.js wabpack生产环境配置

├── config 项目配置

│ ├── dev.env.js 开发环境变量

│ ├── index.js 项目配置文件

│ ├── prod.env.js 生产环境变量

│ └── test.env.js 测试环境变量

├── mock mock数据目录

│ └── hello.js

├── package.json npm包配置文件，里面定义了项目的npm脚本，依赖包等信息

├── src 源码目录

│ ├── main.js 入口js文件

│ ├── app.vue 根组件

│ ├── components 公共组件目录

│ │ └── title.vue

│ ├── assets 资源目录，这里的资源会被wabpack构建

│ │ └── images

│ │ └── logo.png

│ ├── routes 前端路由

│ │ └── index.js

│ ├── store 应用级数据（state）

│ │ └── index.js

│ └── views 页面目录

│ ├── hello.vue

│ └── notfound.vue

├── static 纯静态资源，不会被wabpack构建。

└── test 测试文件目录（unit&e2e）

└── unit 单元测试

├── index.js 入口脚本

├── karma.conf.js karma配置文件

└── specs 单测case目录

└── Hello.spec.js

环境安装

本项目依赖 node.js，使用前先安装 node.js 和 cnpm（显著提升依赖包的下载速度）。

自行下载并安装 node.js： https://nodejs.org/en/download/

然后安装 cnpm 命令：

npm install -g cnpm --registry=https://registry.npm.taobao.org
快速开始
git clone https://github.com/hanan198501/vue-spa-template.git
cd vue-spa-template
cnpm install
npm run dev
命令列表：

开启本地开发服务器，监控项目文件的变化，实时构建并自动刷新浏览器，浏览器访问 http://localhost:8081

npm run dev

使用生产环境配置构建项目，构建好的文件会输出到 "dist" 目录，

npm run build

运行构建服务器，可以查看构建的页面

npm run build-server

运行单元测试

npm run unit

前后端分离

项目基于 spa 方式实现前后端分离，服务器通过 nginx 区分前端页面和后端接口请求，分发到不同服务。前端物理上只有一个入口页面, 路由由前端控制（基于vue-router），根据不同的 url 加载相应数据和组件进行渲染。

接口 mock

前后端分离后，开发前需要和后端同学定义好接口信息（请求地址，参数，返回信息等），前端通过 mock 的方式，即可开始编码，无需等待后端接口 ready。项目的本地开发服务器是基于 express 搭建的，通过 express 的中间件机制，我们已经在 dev-server 中添加了接口 mock 功能。开发时，接口的 mock 数据统一放在 mock 目录下，每个文件内如下：

module.exports = {

// 接口地址

api: '/api/hello',

// 返回数据参考http://expressjs.com/zh-cn/4x/api.html

response: function (req, res) {

res.send(`

<p>hello vue!</p>

`);

}

模块化

开发时可以使用 ES2015 module 语法，构建时每个文件会编译成 amd 模块。

组件化

整个应用通过 vue 组件的方式搭建起来，通过 vue-router 控制相应组件的展现，组件树结构如下：

app.vue 根组件（整个应用只有一个）
├──view1.vue 页面级组件，放在 views 目录里面，有子组件时，可以建立子目录
│ ├──component1.vue 功能组件，公用的放在 components 目录，否则放在 views 子目录
│ ├──component2.vue
│ └──component3.vue
├──view2.vue
│ ├──component1.vue
│ └──component4.vue
└──view3.vue
├──component5.vue
……

单元测试

可以为每个组件编写单元测试，放在 test/unit/specs 目录下面, 单元测试用例的目录结构建议和测试的文件保持一致（相对于src），每个测试用例文件名以 .spec.js结尾。执行 npm run unit 时会遍历所有的 spec.js 文件，产出测试报告在 test/unit/coverage 目录。

联调方式

前后端分离后，由于服务端和前端的开发环境处于2台不同的机器上，前端的异步请求需要代理到后端机器中。联调的时候，只需通过 proxy 参数运行 dev 脚本即可，所有 mock 目录下定义的接口将会转发到 proxy 参数指定的机器：

172.16.36.90:8083 为后端机器的环境地址

npm run dev -- --proxy=172.16.36.90:8083
这样，如果 mock 目录下有定义了接口 /api/hello ，将会转发到 http://172.16.36.90/:8083/api/hello

posted @ 2021-07-01 16:23 woaibaobei 阅读(1725) 评论(0) 编辑收藏举报

刷新页面返回顶部