如何以面向对象的方式对此进行建模

时间:2011-05-23 14:49:17

标签: object oop

我的系统中有以下实体

public class Student
    {
        public Guid StudentId { set; get; }
        public string StudentName { set; get; }
        public virtual Course[] Courses { set; get; }
    }

 public class Teacher
    {
        public Guid TeacherId { get; set; }
        public string TeacherName { get; set; }
        public virtual Course[] Courses { get; set; }
    }


public class Course
    {
        public Guid CourseId { set; get; }
        public string CourseName { set; get; }
        public Student[] Students { set; get; }
        public Teacher Teacher { get; set; } 
        public Test[] Tests{ get; set;}
    }


public class Test
    {
        public Guid TestId { get; set; }
        public String TestName { get; set; }
        public int TotalMarks { get; set; }
        public int PassingMarks { get; set; }
    }

每个学生可以订阅许多课程,每门课程可以有很多学生

每位教师都可以教授很多课程,每门课程都可以有一位老师

每门课程都有很多考试

例如,有一门名为“数学”的课程,持续6个月,在这六个月内进行了多次测试

如果我想存储以下数据,那么正确的数据结构是什么?“对于测试t1的学生S1标记”“对于测试t2的学生s1标记”

我知道我可以在测试和学生之间建立多对多的关系, 但是学生和课程之间已经存在多对多的关系,课程包含测试。

1 个答案:

答案 0 :(得分:1)

你应该考虑有一个课程,比如“标记”,其中包含学生关系 - >马克和马克 - >测试

通常,当您进行面向对象的设计时,在此域级别,您的类和关系是您的用例或描述中的名词和动词。在这种情况下,您知道您的学生有标记;这些都是针对学生的。学生没有考试,因为考试不是由学生创建或控制的。

<强>更新

是的,这个想法是你有一个Marks课程,学生与他们的商标有关系;马克斯与其测试有关系。换句话说,“学生有考试成绩” - 一旦你学会正确看待这些东西,这些东西实际上就是问题的语言。

这就像

class Student { // lots of other fields
    marks : set of Marks  // any convenient structure
                          // logically a Set because you wouldn't have the
                          // same marks assigned to a student twice
}

class Marks {  // A Mark is the Student's score for a test
    Score s;
    Test t;
    Student stud; // see below
}

class Test { // other information needed here too
    marks : set of Marks
}

现在,你有一个课程结构,可以让你问“他们考试中的学生标记是什么?”,你可以问“那些测试是什么?”另一方面,您可以问“这些测试给出了什么标记?”和“那些学生是谁?”这就是为什么马克斯需要与学生建立反向关系。

有两点需要注意:

(1)这是OO分析中非常常见的模式 - 许多关系变成了代表它的“辅助类”。

(2)如果你要把它放在数据库中,还有第二个问题:自然要做的就是让每个类成为一个单独的表;如果您可以以接近零的成本(例如在访问时间内)查找表中的项目,则此方案可以正常工作。在实际数据库中,您必须多次访问磁盘以进行此访问,并且速度变慢。这就是所谓的“对象关系阻抗不匹配问题”。有许多解决方案涉及对数据库进行非规范化,创建额外的索引或视图以预先计算关系,或修改对象模型。

相关问题