starfeng
2004-03-23 11:54

一、DB的统一 VS 接口的统一

使用节点进行简化,操作是方便了些,我觉得还是有可改进之处,如果让我来做,我想我会是这样:

数据库,还将是多种表,至少栏目、内容表是分开的,不同特色的栏目表也是要独立出来的。

对于操作,提供给业务层的操作可以用DAO的方式封装一下,形成统一接口,比方一个基础操作类:Node,然后,也许有针对一些特色栏目的操作,那么你就写Node的子类:Directory.

DAO后面直接用jdbc或是hibernate都行,这些适用于不同对像的操作类也可以用工厂方法封装一下(如果封装,那么Node就要做成一个对所以操作都通用的接口)。

这样做相比原先,我觉得效率肯定是有很大提高,然后业务层的调用操作也方便。

二、权限控制

我注意到了你的权限模型中的两个地方

1.控制到表:db.mysql://192.168.1.31:3306/mysql/user/id=1.user

2.控制到表中某一记录的操作:db.mysql://192.168.1.31:3306/mysql/user/id=1.user#modify?username=jack

首先,一个业务操作是要涉及到多个表的,对于这种情况你如何处理。我也有过这种想法,但因为多表的控制,我放弃了。

对于2,控制到记录,用这种描述是否太过精细,如果user表中有10000记录,可能的操作有view,edit,delete,lock,又设定可以对他操作有level:5人 level2:10人, level3:10000人,level为大版主(all permittion),level2为小版主(自已版块的lock),level3为用户(自已记录的view,edit,delete)。就算采用通配符描述,用于权限控制的总记录也将达:5+10×1000+10000×3 这样的管理方式会导致记录膨涨很厉害。

我觉得对于权限的控制,url的与db的应分开。

url的权限的特点:请求从browser而来(系统外部),对于一个带参url请求,返回:允许 不 允许。

对于一个DB操作(比方,查):请求从server的jsp,servlet,ejb。。而来(系统内部),对于一个操作可能涉及多个表,返回:结果集中的一部分(一部分也可能少到0,这种情况就和url权限相同了)。

对于url用你的那种没问题,对于DB的就得硬编码或sql匹配(权限较简单的情况,门户网站可以采用)。如果非得硬编码也没什么,将系统框架设计好,代码一样清晰。

至于,协议细到ftp,http,https,端口之类,好像没什么必要,对于我权限系统来看就是一个url,透明的。

三、工作流与状态以及事务等等

没这么故意复杂化吧:),这种门户性的东西好像没有什么必要,个人愚见。

zbw
2004-03-23 14:19

首先非常感谢你这么认真的看我写的文档。以前一直没有人这么认真的和我讨论过。

我们可以好好的讨论讨论。

>一、DB的统一 VS 接口的统一

>使用节点进行简化,操作是方便了些,我觉得还是有可改进之处,如果让我来做,我想我会是这样:

>数据库,还将是多种表,至少栏目、内容表是分开的,不同特色的栏目表也是要独立出来的。

>对于操作,提供给业务层的操作可以用DAO的方式封装一下,形成统一接口,比方一个基础操作类:Node,然后,也许有针对一些特色栏目的操作,那么你就写Node的子类:Directory.

>DAO后面直接用jdbc或是hibernate都行,这些适用于不同对像的操作类也可以用工厂方法封装一下(如果封装,那么Node就要做成一个对所以操作都通用的接口)。

>这样做相比原先,我觉得效率肯定是有很大提高,然后业务层的调用操作也方便。

在我的这个设计里,所有的信息都是节点,节点与节点之后,除了存在基本的父子关系之外,还存在着各种可能的其他关系。所有的节点都可以存放在同一个表里,也可以分成N个表。比如说,某个节点,定义自己的子节点的TreeID,然后有一个CoreTree表,定义这个TreeID所在的Table,他们可能是在同一个表里,也可能在不同的表里,甚至可能在不同的数据库,甚至服务器上。

还有一种节点的访问方式我没有写出来,类似于J2EE的JNDI,访问一个节点,只需要给出一个“/aaa/bbb/ccc/ddd/eee”这样的路径,至于这个路径在哪个服务器的那个数据库(甚至不是数据库)的哪条记录,都是无关的。

>二、权限控制

>我注意到了你的权限模型中的两个地方

>1.控制到表:db.mysql://192.168.1.31:3306/mysql/user/id=1.user

>2.控制到表中某一记录的操作:db.mysql://192.168.1.31:3306/mysql/user/id=1.user#modify?username=jack

>首先,一个业务操作是要涉及到多个表的,对于这种情况你如何处理。我也有过这种想法,但因为多表的控制,我放弃了。

>对于2,控制到记录,用这种描述是否太过精细,如果user表中有10000记录,可能的操作有view,edit,delete,lock,又设定可以对他操作有level:5人 level2:10人, level3:10000人,level为大版主(all permittion),level2为小版主(自已版块的lock),level3为用户(自已记录的view,edit,delete)。就算采用通配符描述,用于权限控制的总记录也将达:5+10×1000+10000×3 这样的管理方式会导致记录膨涨很厉害。

>我觉得对于权限的控制,url的与db的应分开。

>url的权限的特点:请求从browser而来(系统外部),对于一个带参url请求,返回:允许 不 允许。

>对于一个DB操作(比方,查):请求从server的jsp,servlet,ejb。。而来(系统内部),对于一个操作可能涉及多个表,返回:结果集中的一部分(一部分也可能少到0,这种情况就和url权限相同了)。

>对于url用你的那种没问题,对于DB的就得硬编码或sql匹配(权限较简单的情况,门户网站可以采用)。如果非得硬编码也没什么,将系统框架设计好,代码一样清晰。

>至于,协议细到ftp,http,https,端口之类,好像没什么必要,对于我权限系统来看就是一个url,透明的。

你看到的这个访问方式,不是一个权限模型,而是信息的统一访问描述。也就是说,当我知道这个信息之后,我会如何去访问(或者说操作)它。

至于权限不是在这里表示的。在我看来,权限也就是节点与节点之间可能存在的关系的一种。

基本的描述是这样的(节点A---节点B---操作1---条件)

这个描述的意思是:如果符合条件节,点A能对节点B进行1号操作。

这个条件可以是一个逻辑表达式,也可以是一个自定义的函数。

当一个节点要对另一个节点进行操作时,我们可以查询一个关系表,如果我们能够找到一条记录,是关于这两个节点的定义的,那么我们就使用这个定义。如果我们不能找到这条记录,那么我们就会去找节点B的父节点(一级一级的往上找),如果找不到,再找节点A的父节点,这样的权限定义,就不会出现你设想的“定义膨胀”的情况。

至于你说的db与url的权限分开,我不能同意,因为他们应该在一个概念体系里得到表达。至于多表查询的情况,那并不是单点操作的概念,本来也不是一般意义上的权限定义的范畴。

在我的设想中,跨越多表的查询,应该自己去写SQL,而跨越多个库,多个服务器的查询,应该另外定义树状查询语言,在内存中进行。

>三、工作流与状态以及事务等等

>没这么故意复杂化吧:),这种门户性的东西好像没有什么必要,个人愚见。

我设想的框架并不只是门户呀。再说随着项目的复杂度的增加,应用与应用之间的界限也会模糊,内网与外网之间的分别也会模糊的。

2Go 上一页 1 2