Допустимое использование статических классов? - PullRequest
0 голосов
/ 09 декабря 2010

Иметь класс, который изначально не должен был быть статическим ...

public class SapApprovalHandler {

    private static SapGs3DataSet sapGs3DataSet;

    static SapApprovalHandler() {
        try {
            // Actually fills the dataset
            sapGs3DataSet = new SapGs3DataSet("SAP");
        }
        catch {
            throw new ApplicationException("Unable to create the SAP-GS3 DataSet");
        }
    }

    public static XElement ProcessApprovals(XElement SapData) {
        // Basically updates the dataset
    }

}

Когда я создавал класс, я решил, что (1) я бы предпочел не пополнять набор данных, если я не обновил его явно, и (2) я являюсь привратником этих данных; никто другой не должен обновлять их. Этот класс вызывается из службы WCF.

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

Чтобы сделать это менее спорным, позвольте мне спросить: каковы недостатки в том, чтобы сделать класс статичным? Причины, по которым я не хочу этого делать.

Не стесняйтесь критиковать подход в целом; обычно я создаю набор данных в ProcessApprovals и избавляюсь от него в конце вызова, но мне действительно не нужно часто обновлять данные, если это вообще необходимо (у меня есть отдельный набор данных с более временными данными, которые я буду обновлять каждые когда я его обновлю, данные SapGs3DataSet действительно не изменятся).

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

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

TIA!
Джеймс

Ответы [ 2 ]

2 голосов
/ 09 декабря 2010

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

0 голосов
/ 09 декабря 2010

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

...