Вопрос архитектуры C #

Question

Я разрабатываю проект, в котором все основные компоненты совместно используют один общий DomainObject (да, я украл термин из мира O / RM, но это не совсем проект O / RM.) DomainObject поддерживает объекты меняют состояние (грязное / чистое) и позволяют себе откатываться или фиксироваться (AcceptChanges (), RejectChanges ()). Когда AcceptChanges () вызывается для объекта, он запускает событие, и это событие инициирует запись значений hte в базовое хранилище данных. Кроме того, он передает параметр, позволяющий отменять постоянство в событии.

1) Создание класса (DomainObject) и изменение его свойств.
2) Classroom.AcceptChanges () вызывается, вызывая OnAcceptEvent и передавая DomainObjectChangeEventArgs, которые содержат логическое свойство с именем Cancel
3) Если событие не отменено, изменения принимаются, и состояние классной комнаты обновляется.
4) Затем проект вызывает AcceptChanges для любых внутренних свойств, которые также являются объектами DomainObject, например Student.
5) Каждый студент запускает событие OnAcceptEvent, передавая DomainObjectChangeEventArgs ... и т. Д.

Теперь, спрашивая сообщество в целом:

A) Если бы у вас был индикатор отмены на AcceptEvent в классе, остановите весь процесс, вынуждая его больше не оценивать и, возможно, не принимайте учеников, или вы бы набрали код Cancel, чтобы просто применить его к классной комнате. b) Можно ли ожидать, что индикатор «Отмена» на каком-либо Студенте остановит обработку на каких-либо дополнительных Студентах?

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

Что бы вы сделали?

Answer 1

Если, скажем, добавление учеников в ваш класс изменяет только состояние класса (например, если вы сохраняете, какой ученик находится в классе в отдельной таблице, количество учеников в классе может увеличиться и т. Д.), Вам не нужно сохранять объект студента в целом.

Если добавление в этот класс или удаление из этого класса приводит к изменению класса ученика (например, количество классов, которые они могут взять и т. Д.), То вы должны также распространить отмену на объекты ученика.

Answer 2

Да, вы должны отменить весь процесс в любом случае. Вы вызываете accept в корне графа объектов, поэтому потребитель будет ожидать, что весь граф будет сохранен. Я бы отнесся к этому как к ситуации «все или ничего».

Answer 3

Я бы назвал событие CanSave, которое возвращает enum {OK, Cancel}. Прежде чем сохранить что-либо, я бы запросил весь граф объектов в поисках отмены. Каждый объект может проверить себя и отменить, если он не находится в состоянии persistable ... предотвращая большинство, но не всех, откатов.

Но что вы можете сделать с помощью Cancel? Один из главных эдиктов хорошего программного обеспечения - « Всегда позволяет пользователю сохранять там работу». Программисты не будут использовать IDE, которая не будет сохранять некомпилируемый исходный код, так почему вы ожидаете, что ваши пользователи будут с этим мириться?

Отмена состояний должно быть действительно исключительными состояниями ... например, не может записать в файл только для чтения -> "Сохранить как" вместо этого? Или пустое поле ключа -> «требуется имя пользователя».

Так в чем же альтернатива? Сохраните в промежуточный формат, который может хранить «недействительные» данные ... как текстовый файл.

В сторону: я часто думал, что приложениям базы данных не хватает кнопки «проверить», позволяющей пользователю узнать «это нормально?» фактически не совершая этого.

Просто пища для размышлений.

Приветствия. Кит.

Answer 4

Я думаю, что вы на деньги.