|
这个主题共有 10 回复 ／ 1 页 [
]
|
|
|
|
|
|
简单问题？
|
发表: 2006年10月12日 12:16
|
回复
|
|
1，大家了角色类在领域建模的时候怎么关联？
比如新闻系统里面的栏目类，建模的时候感觉它不需要和某个用户关联，但是我们在进行添加栏目操作的时候又必须检查它是不是有那个权限。。
2，还有新闻发布系统:struts+hibernate
action----->serviceProxy----->Dao
我就是在action 中直接和serviceProxy联系，然后先用个权限实现serviceProxy，如果权限够就调用业务。
问题在于这样是不是没有松耦合，有没有更好的办法？
是不是action除了和serviceProxy交互外还要和业务等service交互？
3,如果action只和业务代理交互的话，那么业务代理的实现就要包含，检查权限，执行任务了？然后它们共同组合，就是一个事务？
新闻添加事务：检查权限----添加新闻
那么这个事务怎么解耦？有没有通过接口？servicPrxo不和权限类交互，而和权限代理接口交互？那么权限代理接口并不能直接使用自身的方法而需要对它进行初始化，如：interface a=实现一。又需要加一个工厂方法？这样系统不是增加了系统的复杂度？还有没有其他方法？
|
|
|
|
|
|
Re: 简单问题？
|
发表: 2006年10月13日 10:18
|
回复
|
|
》这样系统不是增加了系统的复杂度？还有没有其他方法？
动态代理或AOP
|
|
|
|
|
|
Re: 简单问题？
|
发表: 2006年10月13日 11:08
|
回复
|
|
|
那第一个问题呢？领域建模的时候，用户或者是角色应该不应该和栏目类关联？
|
|
|
|
|
|
Re: 简单问题？
|
发表: 2006年10月26日 00:01
|
回复
|
|
|
是否可以考虑一下通过Filter来管理权限呢?我的想法是限制每个用户访问的路径,比如只有管理员可以访问/yourproject/admin/XXX.do这样的路径,别人访问不了
|
|
|
|
|
|
Re: 简单问题？
|
发表: 2006年10月29日 18:25
|
回复
|
|
|
我要问的不是怎么样实现权限(是用FILTER类实现还是用AOP模式来实现),我是想知道领域建模的时候,角色类是怎么关联的。或者在,第一次:概念模型的时候并不考虑角色类.在进行设计的时候才考虑它,也就是把，领域建模和模型的时候分开,并且领域建模的时候并不考虑全部的因素,只大概的描述项目的需求?
|
|
|
|
|
|
Re: 简单问题？
|
发表: 2006年10月30日 09:51
|
回复
|
|
|
领域建模只是业务建模，当然有时权限会涉及一些业务，但这些都不是我们重点（除非权限系统是业务重点），不管权限是否是业务重点，在具体实现时，权限可以和总是和业务系统达到最大程度的分离，这些我已经在JiveJdon3完全实现，从业务层分离 到表现层。
|
|
|
|
|
|
Re: 简单问题？
|
发表: 2006年10月30日 10:29
|
回复
|
|
>角色类是怎么关联的
另外，角色类关系比较好设计，基本是继承或无关联的关系。
|
|
|
|
|
|
Re: 简单问题？
|
发表: 2006年10月30日 11:09
|
回复
|
|
角色权限和业务模型结合是一个体系问题，涉及系统的各个层：表现层和业务层等。在JiveJdon3中，我目前设计考虑了下面几点：
ACL一般考虑下面情况：方法操作是否有权限访问？资源数据是否有权限访问？数据资源或操作是否允许被显示？详细描述如下：
1. Web资源，主要是以Web URL为特征，对Web资源的Jsp/Servlet 图片等目录下全部资源实现授权访问。
2. 组件资源，同一个组件的不同方法实现对资源进行不同性质的操作，每种操作方法都需要实现授权访问，例如：A角色可以实现帖子创建，但不能实现帖子删除。
3. 模型资源，业务模型只能让特定角色一些访问。比如某个帖子模型只能让积分超过多少的用户访问。其中必须解决与该模型关联的子模型访问权限关系，如帖子的上传图片也必须进行授权访问。
4. 是否需要显示，如果当前用户无权修改帖子，就无需在显示帖子是，输出“修改”链接字样。
解决方案：
1. Web URL资源授权访问，采取基于容器的安全体系，配置web.xml
2. 组件方法授权访问。 采取AOP拦截器方式实现，见PermissionInterceptor
3. 模型资源访问。 采取显式代码实现，见ForumMessageShell
考察整个授权系统，对象生命周期看两种：
1. 全局Application级别的授权规则，如上面Web.xml配置，就是属于全局性质，这类可以用配置实现，组件方法访问授权也属于这一种，使用OperationAuthorization来表达，详细在下一章讨论。
2. 动态Session级别的授权，这类授权需要根据用户动态登录后，根据登录后该用户的角色，再配以动态规则，决定某些资源是否能被操作，例如帖子只有被帖子作者或管理员可以修改。使用ResourceAuthorization表达。
JiveJdon3试运行网址：
http://www.jdon.com/jivejdon/
|
|
|
|
|
|
Re: 简单问题？
|
发表: 2006年10月30日 22:29
|
回复
|
|
谢谢BANQ的解释,我总是以"新闻发布系统"为例子,目的是想让其他初学者象我一样,能够了解到一个项目的全部过程,从需求分析到,编码,测试.
领域建模,根据我现在的了解,在第一步:概念模型的时候,它是不受程序设计语言影响的，从宏观的角度描述一个系统的需求.
然后接下来可能就是设计建模,根据领域建模以及UML,考虑所使用的开发语言进行建模型
接着是开发,测试
我想,关于权限的处理,更多的时候可能是放在"设计建模"这个阶段吧?
|
|
|
|
|
|
Re: 简单问题？
|
发表: 2006年10月31日 11:22
|
回复
|
|
从分析和设计阶段都涉及权限，Evans DDD将分析和设计阶段合并在一起，所以可以说，以后没有分析和设计这两个阶段之分，历史证明：这两个阶段的人为分离造成了很多牛头不对马嘴的软件系统。
现在只有一个阶段：建模。建模将分析和设计统一在一起。
当然，在建模之前有需求，需求我主张使用Use Case，用例来搜集和表达，在用例中，首先明确的就是角色，什么角色做什么事情，所以权限其实从需求一开始就要确定，这个系统给谁用？哪些功能给哪些人用？
在需求后面有一个四色图分析模式，四色图中有一个最重要的就是角色，如果我们把用例需求比喻成一张巨大地图，那么四色图可以说是一个便于观察的放大镜，放大镜能够帮助我们认识和看清楚需求（地图），进而形成我们自己脑海中的隐约模型。
下面，就是使用Evans DDD进行模型轮廓确定以及关联确立，完全进入DDD的模型对象反复确立的迭代过程了。
领域模型确立后，基本可以考虑实现平台：.NET或j2EE，如果是J2EE，还必须考虑J2EE架构选择，Java世界有很多框架，现在是一个框架为王的时代，所以选择好的适合的框架，这些都是领域模型生存运行的土壤。所以，必须搞清楚，我们的平台架构选择是为了领域模型更好生存。
打个比喻，领域模型好像是你从外面买回来的金鱼（当然实际是我们脑海中抽象对象），那么你必须选择适合鱼缸和水，淡水鱼不能放在海水里养，鱼缸和水的选择实际就是平台架构的选择，有时，我们常常在平台架构选择中迷失方向，被各种花言巧语新名词迷惑，没有自己主见，关键实际没有自己的领域建模概念。
只有了自己的领域建模，才能根据自己的模型选择其生存的架构平台，鞋子大小只有自己知道，当然并不是说，拒绝先进，保守，DDD本身是2004年才出来，是新技术，可以说，完全符合DDD要求的框架还没有（包括Ruby on rails），只要符合DDD精神基本可以。
|
|
|
|
|
|
Re: 简单问题？
|
发表: 2006年11月01日 16:44
|
回复
|
|
一般我都是先写好用例,然后在进行领域建模,然后就遇到了在领域模型中角色类不好表示的现象,而且领域建模中没有方法只有属性好象?
如果领域模型完后,再结合四色模型，或者,四色模型是在领域模型的基础上得来.那好象更容易理解些,请问是不是这样一回事?谢谢
我认为光有属性的领域模型并不能诠释整个系统的需求,必定需要一样东西来辅助它.而四色模型从某中角度上来说,是能够诠释系统的.(有属性,有角色,有描述以及业务).
我知道四色模型图,但是不知道怎么使用它.它是领域建模的最后结果，还是领域模型的补充?(也就是说系统需要领域模型表和四色模型表)我怎么感觉四色模型本身就属于领域模型,那以前那种光有属性的模型又是怎么回事
|
|
|
|
注册
登陆
上一主题
下一主题
