我的java学习笔记之杰信商务管理平…

      这个笔记是听陈子枢老师讲的杰信商务平台项目,主要是涉及到一些项目设计和实际开发中的业务场景,主要是分析业务及如何从业务中转换成技术细节以及如何开发一个项目,进入到一个项目组之后如何快速融入并上手,并大力写了很多关于excel导出的poi技术(poi把我们给讲吐了,太多太多),第一次听真实的项目,原来发现这就是这么个项目,基本没啥闪光点,都是增删改查什么吧,但是当时觉得好牛逼,陈老师也是有10多年的开发经验,做过的项目真的是无数啊.看看原始笔记长啥样~~~

概要设计时设计表:数据库建模;

购销合同:销售干的

出口报运:销售干的,只是一部分;--->然后交给船运部门;

装箱单--->HOME_装箱单;(给客户看的,以便确认)

        由船运部门;

委托书:委托车队进行货运;将我们的货委托给车队,即某个车队;

      和他们签订合同,即委托书;

发票:

财务;

六个用例;

用例图针对的是角色,而不是某个特定的人;--->按部门;

内部系统不能有外部人员介入;

销售部-->船运部-->财务

四个部门的人参与到了:

管理员:这个算是部门吗?

销售:

船运

财务

购销合同

出口报运

装箱单

委托书

发票

财务

由用例图整出系统功能结构图;

三句话:项目背景,系统功能,系统特点

三张图:

    用例图,角色+用例:帮助分析,只是过程的产品;

    系统功能结构图;

    数据库建模图;powerdesigner图;

下拉菜单:

不变的东西就写死;

性别都不能写死;有些可能有其他选项,比如,未知,保密,空;

要考虑到具体的业务逻辑;

业务后缀;

表的主键;int:效率高,存储性能,位数小;

UUID:主键;后续程序的兼容性;---建议使用;mysql:36位,数据库自带;---40位长度;正合适;

测试阶段:初始阶段不建外键:到时候正式上线部署时,必须加上外键;测试时的方便;

 

oracle:字段名称都大写,规范;请注意规范; 

实际项目中必须用懒加载;hibernate的核心;

key:子表的外键;

隐藏域放到form下面,紧跟着;看着舒服;

到新公司,根据架构,写出开发步骤;

并熟悉下;

以后就能很快上手;

命名规范:最好与具体的无关;

CLASS_CODE_C:

TEXT_CODE_C:

从子表向父表指向;关联关系的建立

历史数据信息:有些东西不能删除,只设置状态;要么将数据分开存储,因为数据就是钱;

20,30;联系人长度

表的设计要有一定的冗余;提高扩充;

CTYPE,CNOTE:加C避免关键字;不管是java还是其他的;

业务后缀:

_C:customer,业务相关;

_P:权限相关,以后可以复用

_B:基础信息,以后可以复用;

注释要加在关键时候;

formula:不希望在数据库表中出现,但是PO对象中;虚拟列

主键:表名去掉业务后缀+_ID;

以后去公司干活,多想想为什么.

代码分类,代码名称:企业中的通用设计;

数据字典是必有的;

典型的主从结构;不设外键,完全由hibernate进行控制;

inverse:仅仅是少了一条sql语句即外键的更新操作;

跟cascade没有任何关系,cascade是修改本身级联更新对方;

cascade:一般用于delete;

formula:当数据库表之间没有直接关联关系;

但是我们又想利用利用另一个表的数据;可以使用formula;

缺点:效率低,不能大量应用;

关联:使用简单,方便;效率低,比formula稍高;

状态的变迁;

加状态字段的方法和JBPM控制流程如何选用:

1 简单的业务直接使用状态位

2 流程审批记录操作人审批意见,可以加表实现;

  状态位设置的宽一点;

3 工作流系统;JBPM:通用设计;

  最大的优点:

      a:流程回退;很简单;

      b:流程的动态改变:

需求分析:

技术分析;

编码;

数值类型;number;

saveOrUpdate如果有id就是更新;

如果没有id就是保存;

如果我们需要复制entity时,可以将id设置为null;然后在

saveOrUpdate:这时就是新增了,因为id不存在;但是值还在;

/

常用数据的导出的方式:excel方式导出;

1 POI:

2   JXL

    excel2007升级,记录条数

    百万条数;

    效率:

    内存占用;

3 第三方报表工具;

  优点:通用,费用,易用,方便写代码;

  缺点:易维护性差,安装插件;

  兼容性;

  C/S:架构的缺陷,兼容性,或者说环境的阻

  B/S:依赖的是一个浏览器,通用性强;面向浏览器

工具类:常用的用静态,不常用的用非静态,因为静态占内存;

防止文件的并发访问;

POI:好好练练;

开发的时候要快;

关联关系如果层次比较深时,需要增加冗余表,或者说冗余数据来打断这种关联关系;

Sitemesh,Jquery-easyui;

使用代理主键;UUID;

合同ID集合想想老师为什么要这么做;

报运信息---一个报运信息包含了:报运基本信息+货物信息;

设计方案一:

让报运和合同关联:一个报运对应于多个合同;

    基本信息从报运表中取,货物信息从合同中取,因为合同关联着货物;

  即他们之间的关系是:

      一个报运--->多个合同

      一个合同对应于多个货物信息;如果继续深究

      一个货物还对应于多个附件

设计方案二:

    我们自己整一个报运表和一个报运信息表;

    报运表和上面的类似

    报运信息表中包含了:报运表基本信息,这是关联的

    同时还直接包含了货物信息,没有合同这一中介;

    我直接获取货物信息;

    即我们的报运信息和我们的合同信息没有关系

  而是和我们的报运信息表进行关联:一对多还是

报运单的信息:没有货物的附件信息:但是这是组装过的信息;

数据冗余:规范是一方面,实际开发又是一方面;一切从客户需求入手

---这个当做面试时的亮点:

设计尽量简单化:简单是美;

练他们的关联关系;

in 子查询:的拼接;

代码与代码之间,要有适当的空格,以区分;

增强程序的可读性;

开发流程记住:

数据库建模--->PO对象-->映射文件--.Dao-->Action--页面->>struts.xml文件;

名词提炼法

url参数传递注意数据 的隐蔽性;

history.go(-1);//返回上一级页面;

多添加一些实现起来很简单,但是对用户而言很方便的功能;

一对一用于在当一个表中的字段过多,而我们有些时候只需要其中的一部分数据,有些时候需要全部数据;

这个时候考虑使用一对一,对于常用字段,放到主表中,其他不常用的字段另外建表,然后两者关联下;

共享主键;

完整的项目开发流程

需求调研与分析:形成需求规格说明书;同时生成界面原型,原型设计--客户确认需求,签订合同;

概要设计:数据库设计----->详细设计;

编程,单元测试

测试:黑盒,白盒测试

部署试运行,修复bug

正式运行;

上线部署;

运维;

什么时候返还json,什么时候返还success;

1 如果返回简单的直接就用字符串;

2 如果:返回集合往往选择就是json格式;

分时统计访问量,刚开始时什么都没有;

我们把24小时字段做成一个表;

项目描述:

职责描述

技术描述;

需求调研弄到文档里面;

数据库设计;

用户操作文档的编写;

后期维护;

统一数据字典;

宜春市阳光驾校管理系统;

简历写两份;

项目写三个;

自我介绍;

一个学员只能跟一个教练;

一个教练有多个学员;

饼图,报表图;

项目要点:

robots协议: