本篇主要关注通用功能[框架提取]
第一篇关注,概要需求,总体描述,
第二篇关注,模块细节,特殊定制的模块内部流程.
第三篇关注,通用的功能,哪些是可以提取作为基础框架提供的.
- 以前提到框架,总是想到高大上的东东,比如分层,通信,数据库封装,控件封装,画面基类,通用功能,安全,日志,性能等等等..
- 前不久从另一个侧面有了新的体会,框架就是一套解决方案,当我提出问题的时候,你能立马给出方案,并能够对该方案的优点进行描述,让我信服,对开发中可能遇到的各种问题有例子,能测试.简单容易上手.
- 对开发人员来说,框架就是一个框框,一定程度上'限定了'你的自由发挥,但同时极大地缩短了,工作有交叉,以及工作移交时的工作量.当你查看其它人代码的时候,能够很快滴理解明白,因为只要他是用一样的框架,那就应该有'一样的'写法.
整体技术框架
数据库采用sqlserver 2008
开发语言采用C#
与数据库的交互使用ado.net(已有一个疯封装的dll库) 前台采用asp.net
前台控件使用extNet
框架(主页面)
经典的上(标题logo)中(左边菜单树,右边tab页方式的页面)下(底部状态)
简单地extnet提供了tabpanel控件,可动态添加page页.提供treepanel构建菜单树.
treepanel上绑定url地址,点击时动态加载url页面即可
提供画面维护菜单树即可(维护一个树列表)
授权(画面按钮授权)
授权通常分:数据数据,功能授权. 只考虑后者,通常有菜单,画面,按钮授权 为了方便'框架',只授权到菜单项.
在主页面基础上,授权到菜单项(不同用户角色查看不同的菜单项) ,当用户登陆时,构建菜单树即可.
在此基础上,如果需要对画面内的按钮授权,可以在配置菜单的url地址上加参数,页面内读取参数做不同处理.
比如:有一个画面demo.aspx,同时具有增删改查功能.而又不想为查询单独新增一个画面,则可以demo.aspx?action=edit 然后页面内判断如果有edit则显示增删改按钮,否则隐藏
数据库操作类
(这个也待完善,目前没考虑事务的情况)
需提供以下接口
1. 执行某一个sql,返回DataTable,内部判断sql是查询还是非查询,还是存储过程等
2. 执行某一个查询的sql返回DataTable
3. 执行某一个非查询的sql返回int
4. 执行某一个insert方法,传入DataTable,做insert
5. 执行某一个update方法,传入DataTable,做update
6. 执行某一个delete方法,传入DataTable,做delete
数据查询
数据在其他系统维护,(比如存储过程插入,外部系统维护,数据库直接维护等).只需提供查询画面的.
通常上下结构(上方查询条件区域,下方grid列表显示)
extnet很简单,grid绑定用Store,查询的时候后台直接查询到对应的DataTable,设置绑定即可,如果不需要后台分页,控件可自带分页.按钮查询事件最好用js的onclick,首先可以做一些前台必输验证,然后使用 App.direct.XXXXX的方式调用后台的XXXXX方法,传入参数放在前面,后面直接跟回调函数.如
var btnSearchClick = function (btn, e) {
App.direct.BindData({
success: function (result) {App.gridList.selModel.select(0);
}
});
};
后台方法添加[DirectMethod]注解,以上回调中的result对应返回值.
简单数据维护(配置类)
数据增删改的,但不频繁,如配置类的,小代码维护,数据字典,设备维护,电厂维护等.
增删改例子:
日报-月报(月报不用计算汇总)
日报是每天或频繁录入的一些台账信息,信息录入式的.比如药品到货信息,添加剂领取信息等,只管录入不关心计算的.
月报只为了记录编制信息,方便后期导出打印,查看.
日报录入后,按月编制月报,编制的时候只记录编制信息(比如按厂还是按机组,编制月份,编制时间,编制人,审核人,审核以及等)而关联的台账信息,不单独建表关联查询之前录入的数据.
后台表结构A:台账表(通常每种类型台账有一张表) B:月报信息表(各台账共享一个表,至少包含编制月份,编制时间,编制人,审核人,审核意见,状态,台账类型字段)
日报-月报(月报需要计算并将结果落地存储)
与之前的差异在于,编制的月报数据也需要存储.比如对一个月所有数据的汇总.但汇总不是简单的求和或平均,而是需要经过各种算法复杂运算.也有可能对运算后的结果进行更改).
复杂逻辑计算类
- 按设定频率自动执行的,使用sqlserver的代理计划调用存储过程
- 人工触发的,C#类中写逻辑
图形化展示类
- 如果简单的,实时性要求不高,做查询展示的可以直接用extnet的图形控件
- 或可采用netchartdir
报表导出类
采用EPPlus加excel模板文件的方式.(这个应该可以再继续封装一层,做的更通用些,目前还没完善)
1. 最常用的格式,Datatable列表的方式,传入一个datatabe型数据.将数据按多行的方式,指定列顺序,平铺.
FileInfo file = new FileInfo(strFilePath);//strFilePath导出的文件全路径
FileInfo template = new FileInfo(tmpPath); //tmpPath模板文件全路径
using (ExcelPackage package = new ExcelPackage(file, template))
{
//开始遍历的左上角坐标(从左上角开始先行后列,一个个格子设置值)
int x=1,y=1;
//导出的列顺序
List<String> listColIndex = new List<string>() { "powerPlant", "rec_date", "powerGenerate1", "powerGenerate2", "powerGenerateTotal", "powerTotalUsed", "
//取要操作的sheet
ExcelWorksheet worksheet = package.Workbook.Worksheets[1];
//为一些固定格子设置值
worksheet.Cells[1, 1].Value = "";
//按行 遍历传入的数据源 dtContent
for (int i = 0; i < dtContent.Rows.Count; i++)
{
//按列 遍历导出列 列表
for (int k = 0; k < listColIndex.Count; k++)
{
object obj = dtContent.Rows[i][listColIndex[k]];
//指定了行列,设置相应格子值
worksheet.Cells[x + i, y + k].Value = obj;
//设置格子样式
setBorderStyle(worksheet.Cells[x + i, y + k]);
}
}
package.Save();
return strFilePath;
}
文件上传类
extnet封装的上传控件.
- 除了按技术模块的划分,而给出相应的'最佳解决方法'外.(可能不是最佳,但在个性化的方法, 还没能取的同意的情况下,理论上不允许..如果确实有,大家讨论后,定下来新的方法)
- 还有就是规范,编码的规范(数据库表的命名规范,程序变量的命名规范,画面的命名规范,类文件,方法名等),还有文件存放位置.
- 比如数据库表名称已T开头,如果考虑与其他公司表合并,可以再加两位公司代码如TBS,再跟模块名称(通常4位),再加数字序列号..通常表名称与改表维护的前台画面名称一致,如TBSOMOR01在前台对应画面OMOR01.aspx
- 比如控件命名称已控件类型开头,按钮建议btn开头,textbox以txt开头,gridpanel建议以grid开头,如果页面只有一个grid报表的叫gridReport,列表的叫gridList,如果是明确某一张数据库表的grid加表名称,如gridOMOR01,store建议store开头加上表名称(如果表前几位固定,可只取后几位),如果对应的英文大家都清楚,则加英文名称,如storeUser.总之.如果变量只是在画面aspx文件内用到,可以不在乎,比如一些column,label,一些textbox等,但是如果在cs中编码有用到,一定要按规范命名.比如.cs代码上不要出现类似 this.Store1.DataSource=dt;或者string name=textbox1.Text 之类的..
- 比如逻辑方法,建议把与数据调用,相关的尽量单独作为一个serviceXxxx类提供,查询的最好能放一起,比如serviceXxxxQuery.serviceXxxx继承自serviceXxxxQuery.可以以静态方法的方式提供,对外的用public,内部自己调用的用protected
- 比如类内的方法,在serviceXxxxQuery通常有针对各个表的QueryTOMOR01参数可以重载
- 比如在
总之一切为了清晰,统一,无争议,为了养成良好的编码习惯,为了工作交接时无负担,为了方便重构,修改代码.为了后期维护.
另外文档性的,一些在开发的过程中就留意完善的
- 项目方案
- 自检报表
- 程序安装手册
- 系统管理员手册
- 软件使用说明书
- 源程序
- 程序架构说明
- 数据库表结构说明
- 数据库存储过程及触发器说明