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

[wanghui0380]

需求分析。
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等具体的用户类型来继承好

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

[IFocusYou]

说来话长。

[yuan74521940]

SF

[yuan74521940]

继续看问题....

[北京的雾霾天]

(个人观点)
面向对象设计只是一个思路，一种手段，不必拘泥于方式，而是看具体情况来定。
即使前段设计很精致，也避免不了以后代码的改动，要做到“恰到好处”就行了。

[我在地球]

学习

[octverve]

这些东东，应该是你自己根据项目特点来决定的，你问我们，我们也不知道你的程序是怎样个设计框架啊？？就第一个问题，你还是再看看“实体类”的文章吧，我在这说一两句也未必会理解～～～

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

我是直接用公司的成功架构一套了之的｛如果按自己想的来，不一定让我过关（经理，测试人员都太死板了）｝。

[ye.xuan]

与设计模式没有关系

[lishijie910123]

学习哈，
三层架构还需要学习

[danjiewu]

比较同意hbxtlhx的观点。

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

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

怎么设计Check方法就要看业务需求了，最不济的方法就是全部硬编码，只是自己会比较累。比较理想的就是硬编码和配置相结合，因为肯定会有一些“无理”需求需要由硬编码完成，需要把这些硬编码封装，等对业务逻辑比较熟悉了之后也许这些硬编码就能发现出规律了，到时改进Check方法的内部实现就可以了——外部对YourSystem.Check的使用不受影响。

[weir55]

学习

[abcyzq]

狂学习.