Иметь класс, который изначально не должен был быть статическим ...
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!
Джеймс