Как реализовать «управление версиями классов» (используя разные версии одного и того же класса)

Question

Вот проблема: наш основной класс (скажем, контракт) меняется каждый год. Некоторые свойства добавлены, другие удалены. Мы не знаем, как это будет выглядеть в следующем году. Это может сильно измениться или не измениться вовсе.

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

Конечно, мы должны иметь возможность прочитать его обратно ... Один из вариантов (брутальный) - каждый год иметь новый класс контрактов (Contract2008, Contract2009, ...).

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

У вас когда-нибудь были такие проблемы? Любое предложение?

Заранее спасибо!

(Мы используем C # 2.0.)

ДОБАВЛЕНО: Спасибо за ваши ответы. Теперь мы спрашиваем себя, как мы могли бы использовать словарь / XML-файл для реализации контроля версий, не нарушая весь код. Словарь кажется очень сексуальным в этом контексте: о)

Answer 1

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

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

Answer 2

Вполне вероятно, что не нужно реализовывать свойства как свойства C #. На самом деле вы можете хранить свойства в каком-то словаре и использовать методы Get и Set для их чтения / перечисления. В этом случае вы можете использовать один и тот же класс каждый год.

Если свойства действительно имеют свойства , то я бы рекомендовал создавать новую сборку с классом каждый год и загружать сборку динамически. Затем вы можете использовать отражение, чтобы увидеть, какие свойства поддерживаются каждым объектом Контракта. Чтобы упростить вашу жизнь, я бы предложил вам иметь интерфейс для свойств, которые не меняются, и упростить идентификацию класса Contract в сборке.

Answer 3

Первое, что я могу подумать над своей головой. Реализуйте своего рода документ «Возможности». Список (или документ XML), в котором указана версия контакта и какие свойства он содержит.

Каждая функция, которая работает с Контрактом, должна проверять, поддерживаются ли определенные свойства («возможности»).

Например:

Contract2008 Capabilities
-----
has Name
has Stipulations
can DoMagic
-----
>     
>     Contract2009 Capabilities
>     -----
>     has Name
>     has Stipulations
>     can DoMagic
>     -----

Класс контракта будет хранить документ о возможностях и некоторые общие методы установки геттеров.

Contract
  GetCapabilities()
  Set(field, value)  
  Get(field, value)

Функция set и get проверит, поддерживается ли поле в возможностях, перед установкой или получением значения.

(Это должен быть шаблон или что-то в этом роде?)