2013-03-11 1 views
1

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

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

Уровень объекта сохраняемых данных:

ApplicationSettings 
    CommunicationSettings 
    ConfigurationSettings 
     HardwareSettings 
     and so forth some additional levels 

Все эти классы имеют много логики делать разные вещи. Они также имеют информацию о состоянии, которая не должна сохраняться в файле.

Данные постоянно обновляются во время выполнения программы и сохраняются при обновлении до двоичного файла с помощью «бизнес-логики».

Я пытаюсь обновить программу, но выполнение модульных тестов для этого - кошмар.

Я хочу, чтобы данные все равно сохранялись в файле. Но в остальном я открыт для предложений, как улучшить это.

Edit:

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

+0

Как настройки потребляются? Статический класс или передается в конструктор? –

+0

То, что вы описали, является чистой структурой XML, поэтому почему бы не использовать ее? Для управления XML существуют уже установленные инструменты. –

+0

С самого начала почти все классы были статичными. Но после много работы я обновил его, чтобы использовать DI. Итак, теперь все настройки вводятся через конструкторы. – magol

ответ

1

Что я буду делать;

Сначала включите настройки в контракты;

public interface IApplicationSettings 
{ 
    ICommunicationSettings CommunicationSettings{get;} 
    IConfigurationSettings ConfigurationSettings{get;} 
} 

Теперь разбейте свою логику на отдельные проблемы и перейдите в свои настройки на самом высоком уровне; Таким образом, если MyLogicForSomething относится только к настройкам связи, то они передаются только в настройках связи;

public class MyLogicForSomething 
{  
    public MyLogicForSomething(ICommunicationSettings commSettings) 
    { 
    } 

    public void PerformSomething(){/* ... */} 
} 

ICommunicationSettings легко можно выделить здесь; с чем-то вроде Rhino Mocks

Теперь вы можете легко проверить, чтобы убедиться, что-то в настройках называется/устанавливается при запуске логика

var commSettings = MockRepository.GenerateStub<ICommunicationSettings>(); 
var logic = new MyLogicForSomething(commSettings); 

logic.PerformSomething() 

commSettings.AssertWasCalled(x => x.SaveSetting(null), o=>o.IgnoreArguments()); 
+0

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

+0

Перерыв так же (в под логике для каждого типа объекта) проверить, что один объект (или случай состояния) является delt с правильно; то вам нужно только убедиться, что ваш внешний цикл вызывает правильную суб-логику; –

+0

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