2008-09-30 97 views
3

我正在设计一个处理两组数据的应用程序 - 用户和区域。数据是从第三方制作的文件中读取的。我有一个User类和一个Area类,并且数据被读入一个Users数组和一个Areas数组(或者其他适当的内存结构,这取决于我们所使用的技术)。建模相关对象

这两个类都有一个从文件读取的唯一ID成员,而User类包含一个Area ID数组,给出了一个用户与多个Areas关联的关系。

的要求很简单:

  • 用户列表区的
  • 清单指定区域的用户的
  • 名单为指定的用户

地区

  • 清单我首先想到的是将数据留在两个数组中,然后对于每个要求,都有一个独立的方法d根据需要询问一个或两个阵列。这将很容易实现,但我不相信这一定是最好的方式。

    然后我想到了在User类上有'Get Areas'方法和Area类中的'Get Users'成员,如果例如我处于有Area对象的阶段,我可以通过属性找到它的用户,但是如何在Area类上的“获取用户”方法意识到/有权访问Users数组。

    我以前曾经遇到过这个问题,但从来没有真正想出一个明确的解决方案。也许我只是把它变得比实际更复杂。任何人都可以提供任何提示,网址或书籍来帮助我进行这种设计吗?

    更新: 谢谢大家花时间留下一些提示。非常感谢您的意见。

    我同意这个问题的根源是多对多的关系。我理解这将如何在关系数据库中建模,这非常简单。

    我收到的数据是来自第三方的二进制文件的形式,所以我无法控制这些结构,但是当我读取它时,我可以以最好的方式存储它。它有点儿在圆孔中嵌入方块,但我认为读取它然后将其存储在数据库中,那么程序将不得不查询数据库以获得结果。这不是一个大量的数据,所以我认为通过将它存储在内存结构中可以获得我需要的数据。

  • 回答

    0

    为什么不使用DataTable与关系,如果涉及.NET?如果涉及.NET,您也可以再次查看泛型。

    +0

    如果我使用.NET,我会用,而不是数组泛型列表。然而,我并没有太多使用DataTable的经验。我会调查一下。 – Gavin 2008-10-01 10:26:48

    7

    这的确是一个许多一对多的关系,

    User <<--->> Area 
    

    把它分解成3个对象,用户,面积和UserArea:

    User: Id, name, etc. 
    Area: Id, name, etc. 
    UserArea: UserId, AreaId 
    
    2

    是否一个区域属于多个用户?如果是的话,这在技术上是多对多的关系。如果要将数据转换为关系数据库,则需要创建一个包含所有关系的表。我猜如果你想使用数组,你可以创建第三个数组。或者如果你真的想以OO的方式做到这一点,这两个类应该有指向相关区域/用户的指针数组。

    +0

    这就是我在想的那类事情,但并不确定。在指针方面,我必须读取一个数组(或通用列表或其他),读取第二个数组,然后有第三个方法来填充每个数组的指针数组? – Gavin 2008-10-01 10:25:36

    0

    一种选择是为最后2个要求中的每一个使用字典。即,Dictionary<Area, List<User>>Dictionary<User, List<Area>>。您可以在阅读数据时将它们建立起来。你甚至可以围绕这两个字典包装一个类,并且只需要为每个需求提供一个该类的方法。这可以让你确保字典保持同步。

    +0

    我认为你的括号被损坏了 – 2008-10-01 14:29:00

    3

    非常基本的,但这个想法是:

    struct/class Membership 
    { 
        int MemberID; 
        int userID; 
        int areaID; 
    } 
    

    这个类实现了“用户属于区域”成员的概念。 坚持其中一个为集合中的每个成员资格,并查询该集合的子集满足您的要求。

    编辑:另一种选择

    你可以在各成员国的存储区域的列表,并在每个区成员列表。

    面积

    public bool addMember(Member m) 
    { 
        if (/*eligibility Requirements*/) 
        { 
         memberList.add(m); 
         m.addArea(this); 
         return true; 
        } 
        return false; 
    } 
    

    及成员有着相似的应用(没有回调)

    这样做的好处是,它是很容易返回一个迭代通过区域行走,发现会员(反之亦然)

    缺点是它是非常紧密耦合,这可能会导致未来的问题。

    我认为第一个实现更LINQ友好。

    +0

    类似于Steven A. Lowe的想法。我可以做这样的事情,它看起来就像我在关系数据库中的那种模型,但在对象方面,我认为可能有更好的方式让用户的一个实例知道它是关联的用户反之亦然。 – Gavin 2008-10-01 10:22:20

    1

    对不起,但这不是一个面向对象的问题。这是一个关系问题。因此所有对基数的引用(多对多)。这是关系数据库建模101.我并不是要批评加文,只是为了指出一个新的观点。

    那么我的咆哮有什么好处。答案应该是与关系数据存储集成,而不是将其转化为面向对象的范例。这是经典的方形挂钉,圆孔问题。

    0

    与dacracot

    同意也看的DevExpress XPO