Разрешение выборочного сохранения сущностей в приложении MVFM подкачки с использованием LINQ to SQL - PullRequest
0 голосов
/ 06 мая 2011

Я занимаюсь разработкой приложения, которое позволяет редактировать базу данных SQL Server.Проблема, с которой я сталкиваюсь, заключается в том, чтобы позволить пользователю сохранить некоторые изменения, но отменить некоторые другие.Я надеюсь на несколько советов относительно моего дизайна.

Приложение MVVM.В качестве модели я использую классы LINQ to SQL.В общем, у меня есть классы ViewModel для каждого класса сущности.Затем я создаю экземпляр ViewModel для каждого экземпляра сущности

. Интерфейс состоит из одного окна, где я переключаю Views для реализации системы подкачки.По большей части между сущностями, моделями просмотра, представлениями и страницами существует отношение 1: 1.

Проблема, с которой я столкнулся, лучше всего описывается в следующем примере:

Рассмотрим следующие таблицы:

  • Службы
  • StaffMembers
  • StaffMemberAssignments

У меня есть субъект Service.Он представлен в базе данных строкой в ​​таблице «Службы» и имеет такие параметры, как «Имя», «Контрактное значение» и «Тип».
Каждая служба также содержит список StaffMemberAssignments.Назначения StaffMember хранятся в их собственной таблице и содержат некоторые параметры, касающиеся назначений, а также два внешних ключа - один для службы, которой они были назначены, и один для таблицы StaffMember, для присваиваемого StaffMember.

В итоге:
Сервис - StaffMemberAssignment - StaffMember

После редактирования Сервиса (в ServiceView, используя ServiceViewModel на основе одного экземпляра Сервиса), пользователь может "Сохранить изменения »или« Отмена ».Команда «Сохранить изменения» отправляет все изменения в текстовом тексте LINQ to SQL в базу данных.Отмена восстанавливает исходное состояние объекта Сервиса.

Пользователь может добавить StaffMembers к Сервису - это создает StaffMemberAssignments для связи StaffMember с Сервисом.

Здесь начинается сложная часть
Если пользователь хочет добавить StaffMember в Сервис, откроется StaffMembersListView (это таблица с возможностью выбора).Это представление заменяет ServiceView в качестве текущей страницы.После выбора StaffMember, пейджинга вернитесь в ServiceView, и все в порядке, с новым StaffMemberAssignment, созданным для связи StaffMember с Сервисом.
Однако, просматривая список StaffMembers, пользователь может выбрать «Создать нового сотрудника».Откроется StaffMemberView с новым экземпляром StaffMember и моделью представления.Здесь пользователь может ввести данные для нового StaffMember, а затем «Сохранить изменения» или «Отмена».«Отмена» просто возвращает на предыдущую страницу и удаляет вновь созданную сущность StaffMember, а «Сохранить» фиксирует новую сущность в базе данных.Затем возвращается StaffMembersListView, пользователь может выбрать новый StaffMember из списка и вернуться в ServiceView, где было сделано новое StaffMemberAssignment.

Проблема в
КогдаБыл создан новый сотрудник, который сохранил все изменения данных в текстовой базе данных.Это означает, что любые изменения в Сервисе, которыми занимался пользователь, также были перенесены в БД.Если пользователь выбирает «Отменить» службу после создания нового StaffMember, служба не будет возвращена в исходное состояние.

Требуемое поведение заключается в том, что при создании StaffMember и «Save» -dтолько новый StaffMember помещается в базу данных.Пользователь может выбрать его из списка, добавив его в Сервис.Затем, если пользователь отменяет изменения службы, служба возвращается в исходное состояние, но вновь созданный StaffMember останется в таблице StaffMember.В конце концов, оно было сохранено.

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

Окончательное суммирование шагов, приводящих к проблеме:

  1. Пользователь открывает объект службы для редактирования
  2. Пользователь желает выбрать StaffMember для ссылки на службу
  3. Пользователь создает новый StaffMember
  4. Новый StaffMember сохраняется в БД.
    Изменения в Service также сохраняются, но не должны сохраняться.
  5. Пользователь выбираетStaffMember для добавления в Сервис (новый или любой другой)
  6. Пользователь Отменяет изменения в Сервисе. Служба должна вернуться в исходное состояние, но не может из-за сохранения залога на шаге 4.

1 Ответ

0 голосов
/ 06 мая 2011

Не будет ли возможность использовать другой экземпляр контекста модели для создания StaffMember?

...