C # объект равенства для сохранения базы данных - PullRequest
0 голосов
/ 02 апреля 2009

Я хочу узнать, как другие справляются со следующим сценарием.

Это не домашняя работа или какое-либо задание. Примеры классов были созданы, чтобы лучше проиллюстрировать мой вопрос, однако он отражает реальный сценарий, о котором мы хотели бы получить обратную связь.

Мы извлекаем все данные из базы данных и помещаем их в объект. Объект представляет одну запись, и если в базе данных существует несколько записей, мы помещаем данные в список <> объекта записи.

Допустим, у нас есть следующие классы;

    public class Employee
    {
        public bool _Modified;
        public string _FirstName;
        public string _LastName;
        public List<Emplyee_Address> _Address;
    }

    public class Employee_Address
    {
        public bool _Modified;
        public string _Address;
        public string _City;
        public string _State;
    }

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

В базе данных есть таблица для сотрудников и еще одна для адресов сотрудников.

Концептуально мы создаем объект List, представляющий данные в таблицах базы данных. Мы делаем глубокий клон этого объекта, который затем привязываем к элементам управления на переднем конце. Затем у нас есть два объекта (Orig и Final), представляющих данные из базы данных.

Затем пользователь вносит изменения в «конечный» объект, создавая, изменяя и удаляя записи. Затем мы хотим сохранить эти изменения в базе данных.

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

В конечном итоге мы хотим сравнить два объекта List, чтобы мы могли;

  1. Посмотрите, какие свойства были изменены, чтобы изменения могли быть сохранены в базе данных.

  2. Посмотрите, какие свойства (записи) больше не существуют во втором Списке <>, чтобы эти записи можно было удалить из базы данных.

  3. Посмотрите, какие новые свойства существуют в новом списке <>, чтобы мы могли создавать их в базе данных.

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

Надеюсь, я дал понять и с нетерпением жду любых предложений.

Ответы [ 4 ]

1 голос
/ 02 апреля 2009

Добавьте обнуляемое поле ObjectID к базовому типу вашего слоя. Передайте его внешнему интерфейсу и обратно, чтобы увидеть, сохраняется ли конкретный экземпляр в базе данных. Он также имеет много других применений, даже если у вас нет какой-либо карты идентичности

0 голосов
/ 02 апреля 2009

Зачем вам сравнивать два объекта списка? Потенциально вы будете использовать много памяти для дублирования данных.

Я бы предложил иметь свойство status для каждого объекта, которое может сообщить вам, является ли этот конкретный объект Новым, Удаленным или Измененным. Если вы хотите пойти дальше, чем сделать свойство Enum, вы можете сделать его объектом, который содержит своего рода словарь, содержащий изменения для обновления, хотя это, скорее всего, будет применяться только в случае статуса Изменено.

После того, как вы добавили такое свойство, должно быть легко просмотреть ваш список, добавить новые объекты, удалить удаленные объекты и т. Д.

Возможно, вы захотите проверить, как Entity Framework делает подобные вещи.

0 голосов
/ 02 апреля 2009

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

0 голосов
/ 02 апреля 2009

Я бы сделал то же самое, что .NET делает в своих Data классах, то есть сохраняет состояние записи (System.Data.DataRowState) и все связанные версии вместе в одном объекте.

Таким образом:

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