这几天在系统开发的时候,发现一些程序员的编程习惯很不好,这两天发现比较突出的问题就是主细表数据的录入逻辑问题.在这里,我将我的观点写出来用大家探讨,希望可以得到大家拍砖.补充一些建议.主细数据库同时录入数据的时候,我认为有如下原则:
1 逻辑远比方便重要。
有的人喜欢将主表数据之前,生成细表数据。撇开数据库的主外键约束的情况不说,单单从逻辑上,也应该是先有主表数据,然后再有细表数据。
为了绑定显示方便,而将细表数据先存到数据库中,和逻辑上的混乱与造成的麻烦相比,远远得不偿失。 2 临时数据,临时存。
简单的临时数据,可以存到ViewState当中,复杂的(如发表一个新闻,带多个附件的)可以用Session. Session可以放置任何对象。Ctype(Session("FJ"),ArrayList)可以存放很多东西,比如FileUpload。一些技巧应用能带来非常多的好处。但是,不要将临时数据存到数据库中。更不要指望用复杂的判断和清除数据、置标识等方式,貌似很有技巧,实际上是把简单的事情复杂了。 3 事务,事务!
主细表数据一个按钮同时添的时候,要有先有后,有事务,出错就回滚。我的习惯如下
Try
DB.StartTrans()
执行SQL1(主表)
执行SQL2(细表)
执行SQL3(细表)
执行SQL4(细表)
....
DB.Commit()
'提示成功
Catch ex As Exception
DB.RollBack()
'将ex信息提示出来
End Try 如果有一些是调用函数内部有Try了。或者某些执行返回影响行数为0,那就在本页面自己手动Throw一些错误,比如 If Myuser.Insert(参数,参数)=0 Then
Throw New Exception "增加人员失败"
End If
由于我的Insert函数中已经Try了,返回值根据是否为0判断是执行否有错误,那么我就手动Throw出相应的信息。 4 约束关系一定要完整 一个好的程序,不仅仅是代码要逻辑清楚,简捷,健壮.同时,对于数据库,其约束,索引,主键,外键一定要完整.一个好的约束,是避免错误数据产生和简化开发最直接有效的办法.
1 逻辑远比方便重要。
有的人喜欢将主表数据之前,生成细表数据。撇开数据库的主外键约束的情况不说,单单从逻辑上,也应该是先有主表数据,然后再有细表数据。
为了绑定显示方便,而将细表数据先存到数据库中,和逻辑上的混乱与造成的麻烦相比,远远得不偿失。 2 临时数据,临时存。
简单的临时数据,可以存到ViewState当中,复杂的(如发表一个新闻,带多个附件的)可以用Session. Session可以放置任何对象。Ctype(Session("FJ"),ArrayList)可以存放很多东西,比如FileUpload。一些技巧应用能带来非常多的好处。但是,不要将临时数据存到数据库中。更不要指望用复杂的判断和清除数据、置标识等方式,貌似很有技巧,实际上是把简单的事情复杂了。 3 事务,事务!
主细表数据一个按钮同时添的时候,要有先有后,有事务,出错就回滚。我的习惯如下
Try
DB.StartTrans()
执行SQL1(主表)
执行SQL2(细表)
执行SQL3(细表)
执行SQL4(细表)
....
DB.Commit()
'提示成功
Catch ex As Exception
DB.RollBack()
'将ex信息提示出来
End Try 如果有一些是调用函数内部有Try了。或者某些执行返回影响行数为0,那就在本页面自己手动Throw一些错误,比如 If Myuser.Insert(参数,参数)=0 Then
Throw New Exception "增加人员失败"
End If
由于我的Insert函数中已经Try了,返回值根据是否为0判断是执行否有错误,那么我就手动Throw出相应的信息。 4 约束关系一定要完整 一个好的程序,不仅仅是代码要逻辑清楚,简捷,健壮.同时,对于数据库,其约束,索引,主键,外键一定要完整.一个好的约束,是避免错误数据产生和简化开发最直接有效的办法.
void 保存操作()
{
事务控制
onSaveing();
save();
onSaved();}
onSaved和onSaveing是两个虚函数,在每个保存操作之前、之后都有一个事件,像保存之后为列,如果保存完了后判断事件是否为null,如果不为null自然转到overrid onSaved()去了,里面可以写从表的操作.当然是在保存主表的时候从表数据已经有一个返回值了的
void 保存操作()
{
事务控制
onSaveing();
save();
onSaved();}
onSaved和onSaveing是两个虚函数,在每个保存操作之前、之后都有一个事件,像保存之后为列,如果保存完了后判断事件是否为null,如果不为null自然转到overrid onSaved()去了,里面可以写从表的操作.当然是在保存主表的时候从表数据已经有一个返回值了的
1、主从关系的数据操作是否使用事务是由业务规则实现的
有可能必须用事务回滚
有可能不能用事务回滚
2、主从表关系要靠数据库设计表述和约束
好的数据库设计应该把多步操作压缩到最低限度,
楼主所描述的这种关系就属于多步操作;
多步操作尽量依赖MSSqlServer的事务控制(比如表间约束中的Delete层叠和Update层叠),
原因是设计可靠的事务要比设计数据库结构难得多;
我在早期写数据库应用的时候曾经使用大量的事务和触发器,
(触发器机制虽然是系统事务,但写了代码进去后就不一定了)
现在的数据库中根本就没有这两样东西;
3、8楼的观点我补充一下
如果从传统的程序设计角度看,8楼的观点没什么问题;
如果从工业角度看,一个project其实就是一条生产线上的产品,
你有几种项目开发模式(不是设计模式)就算有几条生产线,
不同类型的项目在不同的生产线上生产(比如进销存软件和硬件驱动程序),
这样我们大致划分出几种角色:
车间主任:部门经理(行政管理)
车间组长:项目经理(行政管理)也就是8楼所说的pm
工人:Coder(技术角色)
设计师:Designer(技术角色);
UI、业务逻辑和数据访问都是封装好的,
Coder只知道有哪些组件、都是干什么的,他们只管调用;
就算是新产品,也是Designer交付新的UI组件图纸,由Coder根据图纸先生产UI组件
再由Designer反馈不断迭代后最终确定UI;
所以,一个成熟的软件工厂,部门经理和项目经理必须得了解软件生产的特点,
但不一定精通技术问题,有时候他们懂技术不一定是好事;
大部分的技术问题由Designer解决(当然他们拿的钱最多);
小部分技术问题和体力活(比如代码组装、复制粘贴)由Coder解决(当然他们拿的钱少了) 我们再次回到楼主的话题,
程序员的编程习惯很不好,如果是技术问题,应该在设计阶段解决;
如果不是,那多半是管理问题了,那就找项目经理或部门经理了
设计方案应该根据公司的开发平台编写,那么很多平台中本身就有具有的东西就不需要在设计方案再体现了,比如平台有通用的查询功能,那么则不需要在设计方案体现“根据什么条件查询出哪些结果”,因为这些东西可以由实施人员(而不是程序员)在实施的客户现场进行灵活配置即可,比如开发平台中有工作流系统,那么就不需要在设计方案体现“第一步是哪些审批,第2步是哪些人审批...审批的转向条件是什么”,因为这些都是根据平台提供的功能来灵活配置的。
但是设计方案中有些东西应该体现:如数据库,界面,UML类图序列图等基本的东西
这样项目经理培训好开发平台的用法,然后交给设计方案,剩下的工作就只有给程序员进行测试程序了,呵呵,比较轻松
如果没有开发平台和详细的设计方案东西交给程序员,那项目经理就累吧,整天苦口婆心的教育,连一个界面录入验证都要讨论很长时间
2.而倾向于界面会话的,可以使用界面程序(多使用类等)来完成。关于session、事务和临时表可参考:
http://topic.csdn.net/u/20081119/16/edd5899f-c007-4574-9234-45acfbc532be.html