Проверка Платформы объекта и использование

Что касается вашего первого вопроса, я бы просто реализовал изменения ассоциаций как бизнес-логику. Например, если вы добавляете класс Учителя с несколькими учениками, не добавляйте учеников, таких как

aTeacher.Students.Add(new Student)

, вместо этого создайте метод AddStudent

public Student AddNewStudent(string name, string studentID)
{

    Student s = new Student( name, studentID);
    s.Teacher = this; // changes the association
    return s;
}

. Таким образом, у вас будет полный контроль над изменением ассоциаций. Конечно, именно это мешает другому программисту напрямую добавить ученика? На стороне ученика вы можете сделать сеттер учителя частным (и изменить конструктор, чтобы он принимал учителя или аналогичный). Со стороны учителя, как сделать коллекцию студентов невставляемой? Я не уверен ... возможно, преобразовав его в настраиваемую коллекцию, которая не принимает вставки.

Что касается второй части вашего вопроса, вы, вероятно, могли бы использовать события OnVarNameChanging. Если EntityState имеет значение «New», то вы можете применить свою логику, которая выбирает реальные значения.

Существует также событие, которое срабатывает при сохранении изменений (OnSavingChanges?), Которое вы можете использовать для определения новых объектов и установки некоторых значения.

Но, возможно, самое простое решение - всегда устанавливать значения по умолчанию в конструкторе, и они будут перезаписаны, если данные загружаются из БД.

Удачи

Создайте фабрику, которая будет производить экземпляры для вас в зависимости от ваших потребностей, например:

getStudent(String studentName, long studentId, Teacher teacher) {
    return new Student(studentName, studentId);
}

getStudentForDBInseration(String studentName, long studentId, Teacher teacher) {
    Student student = getStudent(studentName, studentId);
    student = teacher;
    //some entity frameworks need the student to be in the teachers student list
    //so you might need to add the student to the teachers student list
    teacher.addStudent(student);
}

Серьезный недостаток - отсутствие события AssociationChanging (наследуемого от CancelEventArgs ).

Меня это тоже очень беспокоит, поэтому я сообщил об этом в Microsoft Connect Пожалуйста, проголосуйте здесь!

И, кстати, я также думаю, что это также глупо, что PropertyChangingEventArgs не наследует CancelEventArgs, поскольку отмена с исключением не всегда является элегантным решением, кроме того, выброс исключений требует большей производительности, чем вызов OnPropertyChangingEvent, а затем проверьте возвращенный e.Cancel, поэтому он стоит меньше, чем вызов PropertyChangingEvent, который вы в любом случае называете обоими.
Также в обработчике в любом случае может быть сгенерировано исключение вместо того, чтобы отмечать e.Cancel как истинное, для тех, кто настаивает на том, чтобы пойти путем исключения. Голосуйте здесь .