《人月神话》读后感
作者:admin 日期:2008-12-30
能一直留传到现在的软件工程的经典书籍不多，这本书不看,对于搞开发，做软件项目的人来说那就确实有点遗憾了。好不好，不需要我这种小卒子去评论，我把这本书认真的看了三遍。
25年来，软件工程的发展不可同日而语，可做软件项目的精髓思想确实没有多大的改变。---这仅仅是个人的看法。如果做了几个项目再回头来读读这本书，可能很多有切身的体会。比如说：软件项目的乐趣所在，软件项目中的时间管控问题,软件项目中的资源配置问题，这些都很实在，很朴素，可是我们却总不能很好地去做好它，去管控整个项目.大到一个商业系统，小到一个模块，其实都存在一个做项目的思想，可现实中我们很难做到这点。
我读此本书个人的一些体会:
1.是什么让我大学毕业便抛弃自己专业踏入IT的之路？
兴趣，对编程的乐趣，当别人使用你做的系统或软件时那种成就感。这就是如书中所言：职业的乐趣所在:创建事物的快乐，开发对他人有用的东西，将零散的文字组装成一个有用的东西，不断学习的乐趣，创造性的工作。 这些确实是吸引我一直在这路上奔波的东西。
2.是什么困扰我们的项目不能按时交付的因素？
缺乏合理的时间进度管控是造成项目滞后的主要原因。 有些时候对于乐观，有些时候过于妥协，常常缺乏坚持。做了几个项目，发现自己在时间管控方面需要努力，当然，客户的不确实需求因素也常常会左右我的决定--毕竟，在企业做IT项目与纯粹的软件公司做软件项目有不一样的地方。
3.很多项目的失败，是因为彼此之间缺乏沟通以及交流的结果
这点我深有体会，因为我吃过大亏。很多时候在制造性企业做IT，客户的前期需求有很大的不确定性，可能在开始时大家都以为说的是同一个事儿，但当做出来之后客户发现与自己想像的相差太远。同时，用户在操作上的习惯问题也会成为一个不能忽视的因素，这也应该算作是需求的一部分吧。用户与开发项目组如果不在需求上认真“较真”，那以后的问题就会不断涌来了。这些需要靠什么去约束呢？靠文档，靠白字黑字的文档。
4.软件系统可能是人类创造中最错综复杂的事物
往往一个很小的功能，其实也需要开发人员的架构设计方面的完善，对其它模块的影响及扩展,以及代码编写工作。用户在前台可能看到的只是几个文字，实际是中开发人员日夜奋战的结果。很多时候，客户的需求修改，在他们眼里看起来是如此地Easy,可他们却忽视了很多他们看不到的因素---当然，这不是说怪我们的客户。我只是觉得，只有大家彼此沟通，彼此理解，才会做出精品来。
书中还有很多经典的观点，就不用我一一述说了。影响我的另一本好书《代码大全2》也是很值得大家去看看的。
强烈推荐IT人员读此书。
用户权限管理设计(2)
作者:admin 日期:2008-12-23
上篇讲完了数据库的设计，这次我们讲讲在Net中的实现
UI的实现，主要是方便用户操作，考虑用户体验,这个没有什么好说的
后台管理菜单
角色管理列表
新增用户
权限分配
现在，我们根据数据库生成实体类。实体类的设计一般跟数据库的字段相差不大，可以用相关的ORM帮你生成
我们再看看BLL层
我这里是用户-角色的代码，其它的只要根据数据库存储过程就可以看出对应的方法是什么的
UI的实现，主要是方便用户操作，考虑用户体验,这个没有什么好说的
后台管理菜单
角色管理列表
新增用户
权限分配
现在，我们根据数据库生成实体类。实体类的设计一般跟数据库的字段相差不大，可以用相关的ORM帮你生成
我们再看看BLL层
我这里是用户-角色的代码，其它的只要根据数据库存储过程就可以看出对应的方法是什么的
复制内容到剪贴板
程序代码
程序代码 /// <summary>
/// UserRole业务逻辑层
/// </summary>
public class MemberRole:ABC.IDAL.Sys.IMemberRole
{
private static readonly ABC.IDAL.Sys.IMemberRole dal = ABC.DALFactory.DataAccess.CreateMemberRole();
/// <summary>
/// 增加
/// </summary>
/// <param name="Model">Model</param>
/// <returns>bool</returns>
public bool Insert(ABC.Entity.Sys.MemberRoleInfo Model)
{
return dal.Insert(Model);
}
/// <summary>
/// 修改
/// </summary>
/// <param name="Model">Model</param>
/// <returns>bool</returns>
public bool Update(ABC.Entity.Sys.MemberRoleInfo Model)
{
return dal.Update(Model);
}
/// <summary>
/// 删除
/// </summary>
/// <param name="memberRoleID"></param>
/// <returns>bool</return...
/// UserRole业务逻辑层
/// </summary>
public class MemberRole:ABC.IDAL.Sys.IMemberRole
{
private static readonly ABC.IDAL.Sys.IMemberRole dal = ABC.DALFactory.DataAccess.CreateMemberRole();
/// <summary>
/// 增加
/// </summary>
/// <param name="Model">Model</param>
/// <returns>bool</returns>
public bool Insert(ABC.Entity.Sys.MemberRoleInfo Model)
{
return dal.Insert(Model);
}
/// <summary>
/// 修改
/// </summary>
/// <param name="Model">Model</param>
/// <returns>bool</returns>
public bool Update(ABC.Entity.Sys.MemberRoleInfo Model)
{
return dal.Update(Model);
}
/// <summary>
/// 删除
/// </summary>
/// <param name="memberRoleID"></param>
/// <returns>bool</return...
用户权限管理设计(1)
作者:admin 日期:2008-12-13
用户管理权限设计一直是大家讨论的热点，因为几乎涉及到每一个开发的业务系统。我找了很多很多的资料，大家的核心基本上都是一样的:基于角色管理. 用户，角色，模块，权限的相互组合，就可以形成一个强大的权限管理系统。
最近在一个项目中设计的一个用户权限的设计，很乐意与大家一起讨论及分享.
设计思路
我的设计思路或者说是我想要实现的功能
1.用户的权限通过角色来控制,一个用户可以拥有多个角色.
2.用户拥有不同角色时，其权限应该是多个角色相互的补集.
3.一个角色拥有多个模块
4.用户的前台菜单显示根据角色所拥有的模块所决定，不同的用户在前端显示的操作菜单是不一样的。
5.页面中的功能按钮根据模块中所包含的功能所定义，通过模块及角色所拥有的权限进行控制
6.可看某个模块有哪些用户，哪些对应角色,并对其进行特殊权限设置.
7.可以针对单个用户进行特殊设置
我在我的Project中，基本上达到了以上的效果及功能，但在实际过程中发现有些不足之处。因为整个权限设计是基于数据库来设计中，所以数据的读取当数据量大时（我所说的数据量是以万以上来计）可能对性能有一定的影响。但对于一般来说，几千用户之类的我想还是可以承受的。我会在后面说明不足之处。
数据库设计
基本设计：
1.首先,设计数据库.
数据库的设计其实我估计大家都很熟悉了
基本表：用户表，角色表，模块表，功能表,管理员表.如果涉及到企业性质的，可能会根据需要加上组织结构表，群组表等其它辅助表
用户
管理员
角色
模块
(我的模块表考虑了子模块的因素,所以会有深度，父模块ID这两个字段，在后来开发过中，由于思路的转变,IsRootModule,FunctionCode我都没有用到,为了让整个权限系统通变得更通用，我都将其单独设计成了另一个表）
功能表（功能表就是模块对应的功能：增加，删除，修改，详细，列表，浏览，导出，导入之类的）
业务表：用户-角色表 模块-功能表 角色-模块表
要实现一个用户多个角色(1 to n),一个角色多个模块(1 to n),一个模块多个功能(1 to n)，那就得加上几个相关的业务表，之前考虑用视图去实现，我个人之见,视图最好只用来读取数据，不要用来进行数据操作.后来证明是不可取的，这里要注意的就是在实际的业务操作中，应该尽量避免重复的数据录入. 这些表都很简单，但却很关键
用户-角色:
角色-模块：
模块-功能:
大家可以看到，表结构很简单，字段也很少，设计也差不多。都是将相关联的字段ID取出来做数据存取。
视图：用户-角色-模块-功能视图
可能大家会觉得很奇怪，为什么这里出现member_role呢。因为我们在数据表中只存取了ID值，而对应的RoleName字段并没有包含其中，这里的视图就是获取关联表中其他所需要的字段数据了。另外两个视图大家看名字应该就知道他的用处了。
存储过程：各自表的增加，删除，修改，及列表数据. 判断是否存在相同的数据
（CUDLIS-Create, Update,Delete,IfExist,Show,List)
存储过程我就不一一列出了，很简单的，你只要写出下面这些基本上你在开发过程就不会有太多问题了. 注意的是：在相互关联的业务表中，最好能对数据插入进行重复数据判断（用户角色表，模块功能表，角色模块表，尽量避免重复的数据插入）我把大致需要实现的业务列个表给大家参考:
用户表:(Insert ,Update ,IfExist ,Show, Delete)
用户角色表:(Insert ,Update,IfExist,Delete,RoleListByUserID,UserListByRoleID)
角色表:(Insert,Update,IfExist,Show,Delete)
角色模块表:(Insert,IfExist,Delete,Show,RoleListByModuleID,ModulistByRoleID)
模块表:(Insert,Update,IfExist,Show,Dlete,ListByRootModuleID,ListByModuleLevel)
模块功能表:(Insert,Update,Delete,FunctionListByModuleID)
针对用户直接获取其所有的权限时，应该有个单独的Procedure从视图中Member_Role_Module_Function中获取其对应的数据，这样就可以得到想要的东西了。
数据库设计部分应该就这样差不多了。我想这应该是通用的。在实际运用过程中，我个人认为应该有一些改进点：
1.模块与功能部分，可以用字符串的形式将模块对应的功能存在一个数据字段中，这样可能在你的代码编写中可以省下较多的时间并带来更多的便利（主要是可以用split()来代替频繁的数据获取业务）这个我在最初设计中没有想到这点，有点失策.
2.针对N级模块的权限展现问题，如何让父模块继承子模块的权限这个是我没有考虑到的，不过我想应该可以用IsRootModule这个字段来作文章，可惜我还没想到如何去整这个字段。当子模块很多时，在前端UI展示的时候是否会出现很慢的情况？这个我没有去做测试。带有一定的风险
但在前端UI展示我还没想到或实现好的办法，我能想到的应该是像GridViewTree那种不错。
这个权限设计已经在我的Project中运用，暂时没有发现什么问题，而且为我以后对其它系统集成也很有帮助。至于如何在C#中实现业务，个人认为只要知道数据库如何整的，那C#中的业务实现只是一个取数操作过程。下篇与大家再共同分享讨论.
最近在一个项目中设计的一个用户权限的设计，很乐意与大家一起讨论及分享.
设计思路
我的设计思路或者说是我想要实现的功能
1.用户的权限通过角色来控制,一个用户可以拥有多个角色.
2.用户拥有不同角色时，其权限应该是多个角色相互的补集.
3.一个角色拥有多个模块
4.用户的前台菜单显示根据角色所拥有的模块所决定，不同的用户在前端显示的操作菜单是不一样的。
5.页面中的功能按钮根据模块中所包含的功能所定义，通过模块及角色所拥有的权限进行控制
6.可看某个模块有哪些用户，哪些对应角色,并对其进行特殊权限设置.
7.可以针对单个用户进行特殊设置
我在我的Project中，基本上达到了以上的效果及功能，但在实际过程中发现有些不足之处。因为整个权限设计是基于数据库来设计中，所以数据的读取当数据量大时（我所说的数据量是以万以上来计）可能对性能有一定的影响。但对于一般来说，几千用户之类的我想还是可以承受的。我会在后面说明不足之处。
数据库设计
基本设计：
1.首先,设计数据库.
数据库的设计其实我估计大家都很熟悉了
基本表：用户表，角色表，模块表，功能表,管理员表.如果涉及到企业性质的，可能会根据需要加上组织结构表，群组表等其它辅助表
用户
管理员
角色
模块
(我的模块表考虑了子模块的因素,所以会有深度，父模块ID这两个字段，在后来开发过中，由于思路的转变,IsRootModule,FunctionCode我都没有用到,为了让整个权限系统通变得更通用，我都将其单独设计成了另一个表）
功能表（功能表就是模块对应的功能：增加，删除，修改，详细，列表，浏览，导出，导入之类的）
业务表：用户-角色表 模块-功能表 角色-模块表
要实现一个用户多个角色(1 to n),一个角色多个模块(1 to n),一个模块多个功能(1 to n)，那就得加上几个相关的业务表，之前考虑用视图去实现，我个人之见,视图最好只用来读取数据，不要用来进行数据操作.后来证明是不可取的，这里要注意的就是在实际的业务操作中，应该尽量避免重复的数据录入. 这些表都很简单，但却很关键
用户-角色:
角色-模块：
模块-功能:
大家可以看到，表结构很简单，字段也很少，设计也差不多。都是将相关联的字段ID取出来做数据存取。
视图：用户-角色-模块-功能视图
可能大家会觉得很奇怪，为什么这里出现member_role呢。因为我们在数据表中只存取了ID值，而对应的RoleName字段并没有包含其中，这里的视图就是获取关联表中其他所需要的字段数据了。另外两个视图大家看名字应该就知道他的用处了。
存储过程：各自表的增加，删除，修改，及列表数据. 判断是否存在相同的数据
（CUDLIS-Create, Update,Delete,IfExist,Show,List)
存储过程我就不一一列出了，很简单的，你只要写出下面这些基本上你在开发过程就不会有太多问题了. 注意的是：在相互关联的业务表中，最好能对数据插入进行重复数据判断（用户角色表，模块功能表，角色模块表，尽量避免重复的数据插入）我把大致需要实现的业务列个表给大家参考:
用户表:(Insert ,Update ,IfExist ,Show, Delete)
用户角色表:(Insert ,Update,IfExist,Delete,RoleListByUserID,UserListByRoleID)
角色表:(Insert,Update,IfExist,Show,Delete)
角色模块表:(Insert,IfExist,Delete,Show,RoleListByModuleID,ModulistByRoleID)
模块表:(Insert,Update,IfExist,Show,Dlete,ListByRootModuleID,ListByModuleLevel)
模块功能表:(Insert,Update,Delete,FunctionListByModuleID)
针对用户直接获取其所有的权限时，应该有个单独的Procedure从视图中Member_Role_Module_Function中获取其对应的数据，这样就可以得到想要的东西了。
数据库设计部分应该就这样差不多了。我想这应该是通用的。在实际运用过程中，我个人认为应该有一些改进点：
1.模块与功能部分，可以用字符串的形式将模块对应的功能存在一个数据字段中，这样可能在你的代码编写中可以省下较多的时间并带来更多的便利（主要是可以用split()来代替频繁的数据获取业务）这个我在最初设计中没有想到这点，有点失策.
2.针对N级模块的权限展现问题，如何让父模块继承子模块的权限这个是我没有考虑到的，不过我想应该可以用IsRootModule这个字段来作文章，可惜我还没想到如何去整这个字段。当子模块很多时，在前端UI展示的时候是否会出现很慢的情况？这个我没有去做测试。带有一定的风险
但在前端UI展示我还没想到或实现好的办法，我能想到的应该是像GridViewTree那种不错。
这个权限设计已经在我的Project中运用，暂时没有发现什么问题，而且为我以后对其它系统集成也很有帮助。至于如何在C#中实现业务，个人认为只要知道数据库如何整的，那C#中的业务实现只是一个取数操作过程。下篇与大家再共同分享讨论.
《秘密》读书心得
作者:admin 日期:2008-12-12
收到书的时候，被那很精致的封面及包装搞得很意外。先前订购也是因为其嚎头吸引--我好像不知什么时候有了读畅销书的习惯。
书还没看完，但实在看不下去了。这可能跟自己还没到达这个高度吧。通篇书中都在一个“秘密“，一个让大家为之疯狂的秘密。我个人感觉就是有点故弄玄虚的感觉，其实通篇的实质就是把一些哲学上的观点通俗化了。因为考研时背多了马克思主义哲学之流的东西（这可能是我感觉现在受益最大的东西吧），书中的秘密就是其中的一些方法论及世界观的解释吧。当然，这只是我个人的感觉，反正我感觉很多是废话的(就是那些名人们所说的话）
我把自己对书中的一些东西，根据个人的理解，总结了一下.大致主要扯到了这些内容：
1.万事皆有定律，任何事情或事物都要按规律办事。
2.万事皆有矛盾。
3. 做事要用计划，做事要有目标，并保持对目标的关注，促使自己不断的去实现它。
4.要有开放的心态去迎接困难,要懂得感恩。
5.从小事做起，要对自己有信心。
说它是心灵鸡汤是合适的，里面的一些句子不错：
1.要改变你的状况，首先必须改变你的想法.
2.你当下的思想正在创造你的未来。你最常想的，或最常把焦点放在上头的，将会在出现你的生命中，成为你的人生.
3.没有什么是有限的,不论是资源或是其他任何事物；有局限的，只会是人的心。
4.笑，是最佳良药。
5.要让某种关系顺利,就把焦点放在对他人的欣赏上，而非抱怨。当你把焦点放在他们的优点上时，你就会发现他们更多的优点。
6.如果你对待自己,并没有像希望别人对待你的那样，那你永远也无法改变事情的状况。
7.专注于金钱的不足,就不可能在人生中带来更多的金钱。
8.爱的感觉,是你所能发出最高的频率。
9.你拥有改变一切的力量，因为选择思想和感受感觉的，就是你自己。
这个秘密法则就是：思想--变成--事物
我觉得这很像IBM的一个广告里所说的：停止空谈，有了目标就要去实现。我们每个人都会在不同阶段不同范围为自己制定不同的计划或目标，预想目标时雄心壮志，激情澎湃，恨不能马上动手就做,可却很难一直坚持下来。把思想变成事物，确实不是一件简单的事儿，付出的代价是你想像不到的。不过，有付出就有收获，就始终相信这句话。
看来，这本书可以用来睡觉前翻翻看，心情郁闷时拿来瞅瞅，还是不错的。我还里需要去读点哲学上的东西，看来，对这方面的东西极度缺乏。
以上只是个人之见，与大家分享。欢迎指正。
ListBox与数据库的绑定操作
作者:admin 日期:2008-12-11
ListBox,DropDownList,checkBox这几个控件的属性跟使用方法几乎一样，在做系统的进修使用的频率也多。我这里主要与大家分享一下如何用listbox绑定数据据，及增加数据库，从列表中移除选择项的几个操作方法。其实用javascript也完全可以实现。我这里是用服务器端控件与数据库绑定操作来实现的。各有各的的优缺点。
由上图可知：左边的ListBox我是通过DropDownList的选择来进行绑定数据的。所以ListBox是跟上面的部门DropDownList绑定的,所以我应该在DropdownList的selectedx_changed事件中写绑定ListBox的代码
int departmentID = Convert.ToInt32(ddlDepartment.SelectedValue); //获取Dropdownlist中的选择项的值并转成整型
BLL.Sys.Member bllMember = new ABC.BLL.Sys.Member(); //初始化一个BLL业务操作层的对象
if (bllMember.CountByDepartment(departmentID) != 0) //如果绑定的数据总数不为0的情况下
{
lstDeptMember.DataSource = bllMember.ListByDepartment(departmentID, 1, bllMember.CountByDepartment(departmentID)); //业务层绑定方法，也就是listBox的数据来源
lstDeptMember.DataValueField = "MemberID"; //绑定ListBox单项的选择值
lstDeptMember.DataTextField = "TrueName";//绑定ListBox单项的文字值
lstDeptMember.DataBind();
}
else
{
lstDeptMember.Items.Clear(); //清除ListBox的所有项目
ListItem item = new ListItem();
item.Text = "暂时无用户";
item.Value = string.Empty;
lstDeptMember.Items.Add(item);
}
加入所选用户
加入所选用户的Button是对右边所选择的值进行一个简单的for循环检测，选中的加到右边的ListBox中
if (lstDeptMember.SelectedIndex != -1) //lstDeptMember.SelectedIndex!=-1判定是否未选择
...
由上图可知：左边的ListBox我是通过DropDownList的选择来进行绑定数据的。所以ListBox是跟上面的部门DropDownList绑定的,所以我应该在DropdownList的selectedx_changed事件中写绑定ListBox的代码
复制内容到剪贴板 程序代码
程序代码int departmentID = Convert.ToInt32(ddlDepartment.SelectedValue); //获取Dropdownlist中的选择项的值并转成整型
BLL.Sys.Member bllMember = new ABC.BLL.Sys.Member(); //初始化一个BLL业务操作层的对象
if (bllMember.CountByDepartment(departmentID) != 0) //如果绑定的数据总数不为0的情况下
{
lstDeptMember.DataSource = bllMember.ListByDepartment(departmentID, 1, bllMember.CountByDepartment(departmentID)); //业务层绑定方法，也就是listBox的数据来源
lstDeptMember.DataValueField = "MemberID"; //绑定ListBox单项的选择值
lstDeptMember.DataTextField = "TrueName";//绑定ListBox单项的文字值
lstDeptMember.DataBind();
}
else
{
lstDeptMember.Items.Clear(); //清除ListBox的所有项目
ListItem item = new ListItem();
item.Text = "暂时无用户";
item.Value = string.Empty;
lstDeptMember.Items.Add(item);
}
加入所选用户
加入所选用户的Button是对右边所选择的值进行一个简单的for循环检测，选中的加到右边的ListBox中
复制内容到剪贴板 程序代码
程序代码if (lstDeptMember.SelectedIndex != -1) //lstDeptMember.SelectedIndex!=-1判定是否未选择
...
Web技术电子期刊2008年第12期(总第28期)
作者:admin 日期:2008-12-09
ABC作业成本数据平台项目
作者:admin 日期:2008-12-09
ProjectName: ABC
Member:三位专职开发兼测试，外加相关使用人员互补测试
Requirement:需求就比较麻烦了，因为涉及公司机密，就不一一描述。总之，这是一个具有BKK特色的ABC作业成本分析平台.
开发环境：Vs2008Team + SQL2000
系统设计工具：starUML
系统文档生成工具：MS SandCastle
相关文档：有兴趣的不妨搜索一下以下文章
系统管理员的Usercase:
设计思路：
因为不同部门不同人员所看到的模块及功能不一样，所以这里就要考虑到比较复杂的一个权限操作。至于其它的基本模块，由于还没涉及到复杂的报表操作，只是简单的增删除改操作。每个模块的功能主要是增加，删除，修改，导入，导出，查询，详细，这些通用的基础功能。当然还包括各字段各表单的相互关联，比如产品，部门与各个模块间的关联。为了以后的整合方便，我们采用了接口设计来为以后的功能扩展作好基础.而基于整个系统的架构，我们还是采用通用的petshop模式。在用户界面方面，使用了VS.Net自带的Ajax控件，尽量避免页面不断刷新。在输入数据方面也用了比较多的小功能，方便基层的录入员操作。系统整个UI设计是通过ASP.NET的theme去控制的。当然，除了两个登录界面.作UI还是要花一点功夫的。同时还要考虑不同浏览器不同显示器不兼容的情况。
系统架构:
登录界面：
