鉴于目前坛子里多是界面问题,现问一个有关逻辑设计方面的问题,算提高点问题水准!

wanghui0380 2007-10-15 02:21:39
需求分析。
1.有多种类型用户需要使用该系统
2.各种客户需要的权限配置不一样,而且目前情况下尚无一个统一的权限配置方案(呵呵,客户方面讲不清除具体有多少种客户类型以及操作限制,只知道有多种用户类型,权限看情况办)
3.鉴于上面的不明确的需求设计一个方案

我目前的设计如下:
一。用户信息接口
   
interface Iuserinfo //用户信息接口
{
//属性

int userid //用户编号
{
get;
set;
}

DataSet myds //返回用户信息的dataset
{
get;
set;
}

//方法
DataSet getuserById();//根据userid返回用户信息dataset

DataSet setUserById(); //根据userid更新用户信息

bool checkUser(string username,string password); //验证用户
}



二。用户权限接口

interface Iauthority //用户权限接口,这部分暂时没想明白,放了一个空接口
{
}


三 用户基类

class user
{
}

四:administrortar类(因为是个管理系统,用户参与最多的部分是admin部分,其他用户都是对外信息交互部分,参与较少,所以下一步在考虑进来)

 
class adminuser:user,Iuserinfo,Iauthority
{

}
[


五,一个工厂类:系统可能根据不同状况去继承user类生成不同的用户类型的类,工厂类则根据情况返回不同的用户类型类


我现在的困惑:
一。一些基本属性,如用户名称等等是放入user类好,还是放入具体用户类型里好
二。接口继承由user直接继承Iuserinfo,Iauthority好,还是由adminuser等具体的用户类型来继承好

另外:我想问一下各位达人,如果抛开我的设计,各位大大如果遇到这种情况会如何设计这个东东
...全文
190 11 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
11 条回复
切换为时间正序
请发表友善的回复…
发表回复
abcyzq 2008-10-16
  • 打赏
  • 举报
回复
狂学习.
weir55 2007-10-17
  • 打赏
  • 举报
回复
学习
danjiewu 2007-10-15
  • 打赏
  • 举报
回复
比较同意hbxtlhx的观点。

对于你的设计有几个建议。
类、接口的功能越单一越好,实体类除了自身的基本属性外,最好不要提供什么操作。像getuserById,setUserById,checkUser这些并不是用户类固有的,而且将来还会不断有其他操作加入。

设计的时候尽量和现实世界里越“像”越好,把问题分解为 谁 对什么/通过什么 干什么/得到什么 等等,比如你的权限问题,可以描述为 系统 对用户的操作(和操作对象/类型) 进行判断。一般来说系统可以通过静态类实现,这样的话就可以定义方法YourSystem.Check(User user, OperatorEnum op, object target)
user当然是当前用户,也可以不用参数。
OperatorEnum是表示操作的枚举类型,比如添加、删除、查看或者你自己定义的操作等等。
target是操作对象,需要把订单、消息等等都看作是对象,而不是一个个DataRow,否则的话这些都是白说。
如果客户能够认可这种检查权限的方式,剩下的就是确定有哪些操作,一般来说CRUD就已经足够了。还有就是要确定你所说的权限配置,一般来说这个是一个长期的过程-_-#一个建议是你完成设计后让客户去维护权限的配置,只要你的方案简单易懂的话,客户应该是会同意的,对大家都有好处。

怎么设计Check方法就要看业务需求了,最不济的方法就是全部硬编码,只是自己会比较累。比较理想的就是硬编码和配置相结合,因为肯定会有一些“无理”需求需要由硬编码完成,需要把这些硬编码封装,等对业务逻辑比较熟悉了之后也许这些硬编码就能发现出规律了,到时改进Check方法的内部实现就可以了——外部对YourSystem.Check的使用不受影响。
lishijie910123 2007-10-15
  • 打赏
  • 举报
回复
学习哈,
三层架构还需要学习
xuan.ye 2007-10-15
  • 打赏
  • 举报
回复
与设计模式没有关系
octverve 2007-10-15
  • 打赏
  • 举报
回复
这些东东,应该是你自己根据项目特点来决定的,你问我们,我们也不知道你的程序是怎样个设计框架啊??就第一个问题,你还是再看看“实体类”的文章吧,我在这说一两句也未必会理解~~~

另外:我想问一下各位达人,如果抛开我的设计,各位大大如果遇到这种情况会如何设计这个东东

我是直接用公司的成功架构一套了之的{如果按自己想的来,不一定让我过关(经理,测试人员都太死板了)}。
我在地球 2007-10-15
  • 打赏
  • 举报
回复
学习
北京的雾霾天 2007-10-15
  • 打赏
  • 举报
回复
(个人观点)
面向对象设计只是一个思路,一种手段,不必拘泥于方式,而是看具体情况来定。
即使前段设计很精致,也避免不了以后代码的改动,要做到“恰到好处”就行了。
yuan74521940 2007-10-15
  • 打赏
  • 举报
回复
继续看问题....
yuan74521940 2007-10-15
  • 打赏
  • 举报
回复
SF
IFocusYou 2007-10-15
  • 打赏
  • 举报
回复
说来话长。

62,243

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术交流专区
javascript云原生 企业社区
社区管理员
  • ASP.NET
  • .Net开发者社区
  • R小R
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

.NET 社区是一个围绕开源 .NET 的开放、热情、创新、包容的技术社区。社区致力于为广大 .NET 爱好者提供一个良好的知识共享、协同互助的 .NET 技术交流环境。我们尊重不同意见,支持健康理性的辩论和互动,反对歧视和攻击。

希望和大家一起共同营造一个活跃、友好的社区氛围。

试试用AI创作助手写篇文章吧