阿里百秀项目实践---02准备工作

02准备工作

准备工作

  • 数据库设计
  • 基础结构搭建

数据库设计

根据我们的业务需要设计数据库的结构,这个过程是每个项目开始时所必须的,一般由专门的 DBA 角色完成(很多没有划分的非常具体的公司由后端开发人员兼任)。

选项表(options)

用于记录网站的一些配置属性信息,如:站点标题,站点描述等

字段 描述 备注
id ?? 主键  
key 属性键 snake_case
value 属性值 JSON 格式

用户表(users)

用于记录用户信息

字段 描述 备注
id ?? 主键  
slug URL 别名  
email 邮箱 亦做登录名
password 密码  
nickname 昵称  
avatar 头像 图片 URL 路径
bio 简介  
status 状态 未激活(unactivated)/ 激活(activated)/ 禁止(forbidden)/ 回收站(trashed)

文章表(posts)

用于记录文章信息

字段 描述 备注
id ?? 主键  
slug URL 别名  
title 标题  
feature 特色图像 图片 URL 路径
created 创建时间  
content 内容  
views 浏览次数  
likes 点赞数  
status 状态 草稿(drafted)/ 已发布(published)/ 回收站(trashed)
user_id ?? 用户 ID 当前文章的作者 ID
category_id ?? 分类 ID 当前文章的分类 ID

提问:为什么要用关联 ID?

<!-- 答:数据同步,便于维护 -->

分类表(categories)

用于记录文章分类信息

字段 描述 备注
id ?? 主键  
slug URL 别名  
name 分类名称  

评论表(comments)

用于记录文章评论信息

字段 描述 备注
id ?? 主键  
author 作者  
email 邮箱  
created 创建时间  
content 内容  
status 状态 待审核(held)/ 准许(approved)/ 拒绝(rejected)/ 回收站(trashed)
post_id ?? 文章 ID  
parent_id ?? 父级 ID  

点击下载:初始化数据库脚本


搭建项目架构

项目最基本的分为两个大块,前台(对大众开放)和后台(仅对管理员开放)。

一般在实际项目中,很多人会把前台和后台分为两个项目去做,部署时也会分开部署:

  • 前台访问地址https://www.wedn.net/
  • 后台访问地址https://admin.wedn.net/

这样做相互独立不容易乱,也更加安全。但是有点麻烦,所以我们采用更为常见的方案:让后台作为一个子目录出现。这样的话,大体结构就是:

  • 前台访问地址https://www.wedn.net/
  • 后台访问地址https://www.wedn.net/admin/

基本的目录结构

└── baixiu ······································ 项目文件夹(网站根目录)    ├── admin ··································· 后台文件夹    │   └── index.php ··························· 后台脚本文件    ├── static ·································· 静态文件夹    │   ├── assets ······························ 资源文件夹    │   └── uploads ····························· 上传文件夹    └── index.php ······························· 前台脚本文件

基本原则:

  • 先明确一共有多少个页面
  • 一个页面就对应一个 php 文件去处理

?? 源代码: step-01

整合静态资源文件

静态文件 vs. 动态文件

  • 静态文件指的就是服务器不会经过任何处理就返回给客户端浏览器的文件,比如:图片、样式表、字体文件等
  • 动态文件指的就是服务器会对请求的文件进行处理,并将处理后的结果返回给客户端浏览器的文件,比如:PHP 文件、ASP 文件、JSP 文件

具体操作

由于 Apache / Nginx 这一类 Web Server 本身可以处理静态文件请求,所以不需要 PHP 处理静态文件请求。只需要将静态资源放到网站目录中,即可访问

└── baixiu ······································ 项目文件夹(网站根目录)    ├── ......    ├── static ·································· 静态文件夹    │   ├── assets ······························ 资源文件夹+   │   │   ├── css ····························· 样式文件夹+   │   │   ├── img ····························· 图片文件夹+   │   │   ├── js ······························ 脚本文件夹+   │   │   └── venders ························· 第三方资源    │   └── uploads ····························· 上传文件夹+   │       └── 2017 ···························· 2017 年上传文件目录    ├── ......
注意:
  • static 目录中只允许出现静态文件。
  • assets 目录中放置网页中所需的资源文件。
  • uploads 目录中放置网站运营过程中上传的文件,如果担心文件过多,可以按年归档(一年一个文件夹)。

?? 源代码: step-02

项目配置文件

由于在接下来的开发过程中,肯定又一部分公共的成员,例如数据库名称,数据库主机,数据库用户名密码等,这些数据应该放到公共的地方,抽象成一个配置文件 config.php 放到项目根目录下。

这个配置文件采用定义常量的方式定义配置成员:

/** * 数据库主机 */define(‘DB_HOST‘, ‘127.0.0.1‘);?/** * 数据库用户名 */define(‘DB_USER‘, ‘root‘);?/** * 数据库密码 */define(‘DB_PASS‘, ‘wanglei‘);?/** * 数据库名称 */define(‘DB_NAME‘, ‘baixiu‘);

注意:这种只有服务端代码的 PHP 文件应该去除结尾处的 ?>,防止输出内容

在需要的时候可以通过 require 载入:

// 载入配置文件require ‘config.php‘;?...?// 用到的时候echo DB_NAME;

?? 源代码: step-03

载入脚本的几种方式对比

  • require
  • require_once
  • include
  • include_once
  • 共同点:

    • 都可以在当前 PHP 脚本文件执行时载入另外一个 PHP 脚本文件。
  • requireinclude 不同点:
    • 当载入的脚本文件不存在时,require 会报一个致命错误(结束程序执行),而 include 不会
  • once 后缀的特点:
    • 判断当前载入的脚本文件是否已经载入过,如果载入了就不在执行

提问:由以上几种方式的对比可以得出:在载入 config.php 时使用哪种方式更合适?

<!-- 答:require_once,原因有二:1. 载入失败无法继续执行;2. 不能重复载入 -->

显示 PHP 错误信息

当执行 PHP 文件发生错误时,如果在页面上不显示错误信息,只是提示 500 Internal Server Error 错误,应该是 PHP 配置的问题,解决方案就是:找到 php.ini 配置文件中 display_errors 选项,将值设置为 On

; http://php.net/display-errors; display_errors = Offdisplay_errors = On?; The display of errors which occur during PHP‘s startup sequence are handled

项目架构总结

架构的目的就是搭建一个基本的架子或者说是制定一个基础的约束,让所有的开发人员基于这一个约束基础之上展开开发工作。

有利于后期维护(不至于写一段时间过后大家都不认识这个项目,找一个文件,找一个功能找半天)

例如 venders 目录

<!-- TODO: 为什么要这么设计 --> <!-- 1. 一个请求对应一个文件处理方式 --> <!-- 2. 单一入口应用程序方式 -->


开始编码

对于网站功能开发人员来说,他们在展开工作之前就已经完成了静态页面的制作,接下来就是具体开发每一个业务功能。

对于目前我们的情况来说,我们有两种方式:

  1. 先把每一个静态页直接转换成一个对应的 PHP 文件,调整页面中的资源路径,然后在此静态页面可以访问的基础之上实现各个功能。
  2. 一个功能一个功能的来。先明确要做的功能,建立对应的 PHP 文件,然后再把静态页贴进来,实现具体功能。

整合全部静态页面

  1. 将静态页面全部拷贝到 admin 目录中。
  2. 将文件扩展名由 .html 改为 .php,页面中的 a 链接也需要调整。
  3. 调整页面文件中的静态资源路径,将原本的相对路径调整为绝对路径

绝对路径 vs 相对路径(重点掌握)

  1. 不会跟随当前页面的访问地址变化而变化
  2. 更简单明了,不容易出错,不用一层一层的找

?? 源代码: step-04

抽离公共部分

由于每一个页面中都有一部分代码(侧边栏)是相同的,分散到各个文件中,不便于维护,所以应该抽象到一个公共的文件中。

于是我们在 admin 目录中创建一个 inc(includes 的简称)子目录,在这个目录里创建一个 sidebar.php 文件,用于抽象公共的侧边栏 <div class="aside"> ... </div>,然后在每一个需要这个模块的页面中通过 include 载入:

...<?php include ‘inc/sidebar.php‘ ;?>...

提问:为什么使用 include 而不是 require

<!-- 答:侧边栏不会影响其他模块,没有侧边栏其余代码应该也可以继续执行 -->

?? 源代码: step-05

侧边栏的焦点状态

由于侧边栏在不同页面时,active class name 出现的位置不尽相同,所以我们需要区分当前 sidebar.php 文件是在哪个页面中载入的,从而明确焦点状态。

所以目前的关键问题就出现在了如何在 sidebar.php 中知道当前被哪个文件载入了。

通过查看 include 函数的文档发现:如果 a.php 通过 include 载入了 b.php 文件,那么在 b.php 文件中可以访问到 a.php 中定义的变量。

http://php.net/manual/zh/function.include.php

借助这个特性,我们可以在各个页面中定义一个标识变量,然后在 sidebar.php 中通过这个标识变量区别不同页面的载入:

每一个菜单项 <li> 元素:

...<li<?php echo $current_page == ‘dashboard‘ ? ‘ class="active"‘ : ‘‘; ?>>  <a href="index.php"><i class="fa fa-dashboard"></i>仪表盘</a></li>...

对于有子菜单的菜单项,有一点例外:

···<li<?php echo in_array($current_page, array(‘posts‘, ‘post-add‘, ‘categories‘)) ? ‘ class="active"‘ : ‘‘; ?>>  <a href="#menu-posts"<?php echo in_array($current_page, array(‘posts‘, ‘post-add‘, ‘categories‘)) ? ‘‘ : ‘ class="collapsed"‘; ?> data-toggle="collapse">    <i class="fa fa-thumb-tack"></i>文章<i class="fa fa-angle-right"></i>  </a>  <ul id="menu-posts" class="collapse<?php echo in_array($current_page, array(‘posts‘, ‘post-add‘, ‘categories‘)) ? ‘ in‘ : ‘‘; ?>">    <li<?php echo $current_page == ‘posts‘ ? ‘ class="active"‘ : ‘‘; ?>><a href="posts.php">所有文章</a></li>    <li<?php echo $current_page == ‘post-add‘ ? ‘ class="active"‘ : ‘‘; ?>><a href="post-add.php">写文章</a></li>    <li<?php echo $current_page == ‘categories‘ ? ‘ class="active"‘ : ‘‘; ?>><a href="categories.php">分类目录</a></li>  </ul></li>···

?? 源代码: step-06

原文地址:https://www.cnblogs.com/jane-panyiyun/p/12289629.html

时间: 2024-11-08 01:35:49

阿里百秀项目实践---02准备工作的相关文章

阿里百秀项目实践---01项目介绍

01项目介绍 核心目标 了解 Web 开发过程(历史) 掌握基本的动态网站开发 培养 B/S 架构应用开发思维 锻炼 JavaScript jQuery AJAX 项目预览演示 一个自媒体信息发布平台 管理员(编辑)通过网站后台管理界面管理(发布.维护)自媒体内容 用户登录 登录界面可以根据是否填写表单内容拒绝登录操作 管理员可以通过用户名和密码登录到后台 内容管理 管理员可以通过管理后台查看全部内容 管理员可以通过管理后台增加内容 管理员可以通过管理后台删除内容 管理员可以通过管理后台修改内容

始于阿里,回归社区:阿里8个项目进入CNCF云原生全景图

破土而出的生命力,源自理想主义者心底对技术的信念. 云原生技术正席卷全球,云原生基金会在去年KubeCon +CloudNativeCon NA的现场宣布: 其正在孵化的项目已达14个,入驻的厂家或产品已超过300家,并吸引了2.2万开发者参与项目代码贡献,其明星产品Kubenetes 的GitHub 上Authors 和 Issues 量已排行开源领域的第二名. 今年,KubeCon + CloudNativeCon 首次来到中国. 在2018 KubeCon + CloudNativeCon

广告行业中那些趣事系列6:BERT线上化ALBERT优化原理及项目实践(附github)

摘要:BERT因为效果好和适用范围广两大优点,所以在NLP领域具有里程碑意义.实际项目中主要使用BERT来做文本分类任务,其实就是给文本打标签.因为原生态BERT预训练模型动辄几百兆甚至上千兆的大小,模型训练速度非常慢,对于BERT模型线上化非常不友好.本篇研究目前比较火的BERT最新派生产品ALBERT来完成BERT线上化服务.ALBERT使用参数减少技术来降低内存消耗从而最终达到提高BERT的训练速度,并且在主要基准测试中均名列前茅,可谓跑的快,还跑的好.希望对需要将BERT线上化感兴趣的小

第六周作业:《人月神话》对我做项目实践的启示(一)

<人月神话>这本书有两个老师都有给我们推荐,第一个老师推荐时不以为然,第二个老师也推荐时,自己感觉应该是挺重要的吧,于是去图书馆借了这本书来看,刚借回来时,总觉得时间不够.作业很多,也没来的及看,就一直搁置在了那里,直到上周,在我们的项目实践开始近三周,但进度却一直赶不上来的情况下,看到了这本书,才拿起来看.目前还没看完,先写一点儿领悟到的东西. 作者从焦油坑,提出项目失败的表现,把过去几十年的大型系统开发比作一个炼焦坑,各种团队一个个地淹没在焦油坑,他们都试图解决面对的问题,但他们都必须去了

衣起秀项目启动

一.   项目简介 一个专注于穿衣搭配的互动交流平台. 旨在分享自己穿衣搭配的同时通过学习别人的穿衣搭配来找到不一样的自己 用户可通过我们的每日推送学习欣赏时下最流行穿衣搭配,潜移默化的提高自己的穿衣品味. 并且可将所学应用于实践,即用户通过网页.手机客户端来发布自己穿衣搭配的图片以征询其他人的意见. 二.项目实施背景 1.需求分析 调研的时候,我们针对中南民族大学各专业学生发布问卷,问卷显示有很多同学有提高自己穿衣搭配审美的渴望,但是却苦于没有一个提高自己审美的平台: 2.市场分析 调查,我们

LVS (Linux Virtual Server)集群项目实践

LVS (LinuxVirtual Server)集群项目实践 实验目的:通过实验可以熟练规划和配置集群项目 实验环境:Red Hat Enterprise Linux Server release 6.4 实验前提:请确保实验前看过 LVS 中文站点 实验说明:本实验只是以实现负载均衡为目标,并没有考虑如共享存储等,这方面问题在以后的实验中 会添加. 实验步骤: 一.LVS 系统模型 二.LVS 调度算法 三.负载平衡方法 四.常用术语介绍 五.NAT 方式架设 六.DR方式架设 一.LVS

Django项目实践4 - Django网站管理(后台管理员)

http://blog.csdn.net/pipisorry/article/details/45079751 上篇:Django项目实践3 - Django模型 Introduction 对于某一类站点, 管理界面 是基础设施中很重要的一部分. 这是以网页和有限的可信任管理者为基础的界面,它能够让你加入,编辑和删除站点内容. 常见的样例: 你能够用这个界面公布博客,后台的站点管理者用它来润色读者提交的内容,你的客户用你给他们建立的界面工具更新新闻并公布在站点上.这些都是使用管理界面的样例. 创

《Spring Boot 入门及前后端分离项目实践》系列介绍

课程计划 课程地址点这里 本课程是一个 Spring Boot 技术栈的实战类课程,课程共分为 3 个部分,前面两个部分为基础环境准备和相关概念介绍,第三个部分是 Spring Boot 项目实践开发.Spring Boot 介绍.前后端分离.API 规范等内容旨在让读者更加熟悉 SpringBoot 及企业开发中需要注意的事项并具有使用 SpringBoot 技术进行基本功能开发的能力:这最后的项目实战为课程的主要部分,我会带着大家实际的开发一个前后端分离的 Spring Boot 实践项目,

Hangfire项目实践

Hangfire项目实践分享 Hangfire项目实践分享 目录 Hangfire项目实践分享 目录 什么是Hangfire Hangfire基础 基于队列的任务处理(Fire-and-forget jobs) 延迟任务执行(Delayed jobs) 定时任务执行(Recurring jobs) 延续性任务执行(Continuations) 与quartz.net对比 Hangfire扩展 Hangfire Dashborad日志查看 Hangfire Dashborad授权 IOC容器之Au