Как смоделировать эти отношения?

Question

Прежде всего, я проясняю, что я не использую никакой платформы OR Mapper для решения этой проблемы, потому что мне нужно понять модель с нуля.

OK. Давайте посмотрим на таблицы конструкций:

Курс - стол

------------------
 ID | CourseName
------------------
 1  |  C++
 2  |  Java
------------------

Учитель - стол

-----------------------
 ID |   TeacherName
-----------------------
 1  |   Professor X
 2  |   Professor Y  
-----------------------

CourseTeacher - таблица

---------------------------------------------
 ID | CourseID | TeacherID | ClassTime
---------------------------------------------
 1  |   1      |     1     | Monday    10:55
 2  |   1      |     2     | Thursday  10:55
 3  |   2      |     1     | Tuesday   11:45
 4  |   2      |     2     | Wednesday 11:45
---------------------------------------------

Как мне создавать свои классы в C #?

Может быть другая проблема, такая как:

Пользователь - таблица

------------------
 ID | UserName
------------------
 1  |  a
 2  |  b
------------------

Роль - таблица

-----------------------
 ID |   RoleName
-----------------------
 1  |   c
 2  |   d
-----------------------

UserRole - таблица

---------------------------------------------
 ID | UserID | RoleID | Remarks
---------------------------------------------
 1  |   1      |     1     | xy
 2  |   1      |     2     | yz
 3  |   2      |     1     | zx
 4  |   2      |     2     | xx
---------------------------------------------

Answer 1

В общем, когда у вас есть отношение многие ко многим в вашей доменной модели, шаблоны доступа в вашем коде будут либо с одной стороны M2M, либо с другой ...

Например, Если у вас есть структура, содержащая людей, каждый из которых совершил несколько покупок в ваших торговых точках, вы, как правило, можете захотеть получить доступ к этим транзакциям через человека, а не через продукт. иными словами, вам, возможно, чаще захочется узнать, какие продукты приобрел конкретный человек, а не какие продукты приобрел конкретный продукт. Таким образом, в этом примере вы просто хотите, чтобы каждый класс person содержал свойство, представляющее собой набор продуктов. Не будет необходимости обращаться к классу персонажа через класс Product.

Другой, например, Если у вас есть структура, содержащая людей, каждый из которых подписывается на несколько журналов.

Теперь, если вы являетесь издателем, вы, как правило, можете получить доступ к этим транзакциям через журнал, а не через человека. другими словами, вам гораздо чаще хотелось бы знать, что люди подписываются на определенный журнал, а не на какие журналы подписывается конкретный человек. Так что в этом примере вы бы поместили свойство коллекции подписчиков в класс Magazine.

Answer 2

Я думаю, что у вас действительно есть скрытая третья концепция: ClassSession или что-то в этом роде. Каждая сессия ClassSession будет иметь Учителя, Курс и DateTime.

public class ClassSession
{
    public Teacher Teacher { get; set; }

    public Course Course { get; set; }

    public DateTime Time { get; set; }
}

Answer 3

Мой образец:

interface ICourse
{
    string Name { get; set; }
}

interface ITeacher
{
    string Name { get; set; }
}

interface IClassSession
{
    ICourse Course { get; set; }
    ITeacher Teacher { get; set; }
    DateTime Scheduled { get; set; }
}

interface ITransactionalEntity
{
    int ID { get; set; }
}

//sample class implementation
class Teacher : ITeacher, ITransactionalEntity
{
    private int _ID;
    public int ID
    {
        get { return _ID; }
        set { _ID = value; }
    }
    //implement interfaces
    public void Save(SqlTransaction tran)
    {
        if (this.ID > 0)
            //insert
        else
            //update
    }
}

class ClassSession : IClassSession, ITransactionalEntity
{
    //implement interfaces
    public void Save(SqlTransaction tran)
    {
        this.Course.Save(tran);
        this.Teacher.Save(tran);
        if (this.ID > 0)
            //insert
        else
            //update
    }
}

...
List<IClassSession> list = new List<IClassSession>();
ClassSession cs = new ClassSession();
cs.Course = new Course(courseID);
cs.Teacher = new Teacher(teacherID);
classlist.Add(cs);
SqlTransaction tran;
...
foreach(IClassSession classsession in list)
    classsession.Save(tran);
...

и вы можете делать все, что хотите, Linq и т. Д. Используйте свое воображение. Не все здесь написано, просто как идея.

Answer 4

Если вы уже знакомы с отношениями родитель-ребенок, я бы посоветовал вам попытаться смоделировать их как два отдельных отношения родитель-ребенок. Например, есть один экран, который редактирует учителей и позволяет им добавлять существующие курсы. С другой стороны у вас может быть экран курса, который позволяет им добавлять существующие преподаватели. Следование этому совету должно облегчить вашу работу. Исходя из дизайна класса, вы бы смоделировали его таким же образом. В классе курса будет метод добавления учителей во внутренний список учителей. В классе «Учитель» также есть метод добавления курсов во внутренний список курсов. Физическая структура классов действительно зависит от того, как вы планируете сохранять объекты. Постоянство на основе файлов, сериализация xml и постоянство базы данных могут иметь различные внутренние структуры объектов. Существуют также различия в классе, если вы моделируете на уровне сущности или на уровне бизнес-уровня. В любом случае, надеюсь, я дал вам достаточно идей, чтобы работать с ним.