#wpf #linq-to-sql #mvvm #commit
#wpf #linq-to-sql #mvvm #фиксация
Вопрос:
Я разрабатываю приложение, которое позволяет редактировать базу данных SQL Server. Проблема, с которой я сталкиваюсь, заключается в том, что пользователю разрешено сохранять некоторые изменения, но отбрасывать некоторые другие. Я надеюсь на некоторые советы относительно моего дизайна.
Приложение является MVVM. В качестве модели я использую классы LINQ to SQL. В общем, у меня есть классы ViewModel для каждого класса объектов. Затем я создаю экземпляр ViewModel для каждого экземпляра объекта
Интерфейс состоит из одного окна, в котором я переключаю представления для реализации системы подкачки. По большей части, существует соотношение 1: 1 между объектами, ViewModels, представлениями и страницами.
Проблема, с которой я сталкиваюсь, лучше всего описывается следующим примером:
Рассмотрим следующие таблицы:
- Услуги
- Сотрудники
- StaffMemberAssignments
У меня есть объект, Service. Он представлен в базе данных строкой в таблице Services и имеет такие параметры, как «Name», «ContractValue» и «Type».
Каждая служба также содержит список назначений StaffMember. Назначения StaffMember хранятся в их собственной таблице и содержат некоторые параметры, касающиеся назначений, а также два внешних ключа — один для службы, где они были назначены, и один для таблицы StaffMember, для назначаемого StaffMember.
В итоге:
Service — StaffMemberAssignment — StaffMember
После редактирования сервиса (в ServiceView с использованием ServiceViewModel на основе одного экземпляра сервиса) пользователь может «Сохранить изменения» или «Отменить». Команда «Сохранить изменения» отправляет все изменения в datacontext LINQ to SQL в базу данных. Отмена восстанавливает объект службы в исходное состояние.
Пользователь может добавлять StaffMembers в службу — это создает StaffMemberAssignments для привязки StaffMember к службе.
Здесь начинается сложная часть
Если пользователь хочет добавить сотрудника в службу, открывается StaffMembersListView (это таблица с возможностью выбора). Это представление заменяет ServiceView в качестве текущей страницы. После выбора StaffMember возврат подкачки к ServiceView, и все в порядке, с новым StaffMemberAssignment, созданным для привязки StaffMember к сервису.
Однако при просмотре списка StaffMembers пользователь может выбрать «Создать нового сотрудника». Откроется StaffMemberView с новым экземпляром StaffMember и viewmodel. Здесь пользователь может ввести данные для нового сотрудника, а затем «Сохранить изменения» или «Отменить». «Отмена» просто возвращает на предыдущую страницу и удаляет вновь созданный объект StaffMember, в то время как «Сохранить» фиксирует новый объект в базе данных. Затем возвращается StaffMembersListView, пользователь может выбрать нового сотрудника из списка и вернуться к ServiceView, где было произведено новое назначение сотрудника.
Проблема в том,
При создании нового Staffmember его сохранение перенесло все изменения datacontext в базу данных. Это означает, что любые изменения в Службе, с которой был занят пользователь, также были перенесены в базу данных. Если пользователь решит «Отменить» службу после создания нового сотрудника, Служба не будет возвращена в исходное состояние.
Желаемое поведение заключается в том, что при создании StaffMember и «Save»-d в базу данных передается только новый StaffMember. Пользователь может выбрать его из списка, добавив в Службу. Затем, если пользователь отменяет изменения службы, служба возвращается в исходное состояние, но вновь созданный StaffMember останется в таблице StaffMember. В конце концов, оно было сохранено.
Поиск в Google способов выборочного сохранения объектов создал у меня впечатление, что этого не предполагается делать. Итак, как я могу изменить свой дизайн слоя данных или дизайн пользовательского интерфейса, чтобы получить желаемую функциональность? Или то, что я хочу, нереально?
Окончательное суммирование шагов, ведущих к проблеме:
- Пользователь открывает объект Service для редактирования
- Пользователь желает выбрать StaffMember для ссылки на Service
- Пользователь создает нового сотрудника
- Новый сотрудник сохраняется в базе данных.
Изменения в службе также сохраняются, но их не следует сохранять. - Пользователь выбирает сотрудника для добавления в Службу (нового или любого другого)
- Пользователь отменяет изменения в службе. Служба должна вернуться в исходное состояние, но не может из-за сопутствующего сохранения на шаге 4.
Комментарии:
1. Все еще очень надеюсь получить исчерпывающий ответ на этот вопрос. Я рассматриваю проект, в котором ViewModel считывает параметры модели (в данном случае объекта), но не обновляет их напрямую. Затем пользователь может редактировать представление и, следовательно, ViewModel, но только при выполнении команды сохранения представления изменения в ViewModel передаются в модель, а изменения datacontext фиксируются в БД. Как это соотносится с лучшими практиками MVVM и LINQ to SQL?
Ответ №1:
Не было бы вариантом использовать другой экземпляр контекста модели для создания StaffMember?
Комментарии:
1. На данный момент мой datacontext существует в течение всего срока службы приложения. То, что вы предлагаете, может сработать. Как бы я обобщил это для дизайна, который работает для всех страниц, имеющих параметры сохранения и отмены? Конечно, я не могу создать новый DataContext для каждого изменяемого объекта?