I would like to clarify whether this practice of working with the settings object is considered correct. There is an object inside the application that stores all the current parameters in memory:

public class Settings : ICloneable { public string Code1{get;private set;} public string Code2{get;private set;} private Settings _actualSettings; public Settings(string code1,string code2) { Code1 = code1; Code2 = code2 } public void UpdateSettings(string code1,string code2) { Code1 = code1; Code2 = code2; Commit(); } public void Commit() { _actualSettings = (Settings) Clone() } public object Clone() { return new Settings { Code1 = Code1 , Code2 = Code2 }; } } public Settings GetSettings() { return _actualSettings; }

There may be many settings that change absolutely from different places and there may be many overloads of the UpdateSettings method (only some parameters can be updated)

Settings are requested in different places and it is necessary that at one time the working version of the settings for all users is the same.

Is such a mechanism correct from an architectural point of view? If not, how to organize such a storage in memory?

  • If the application is multi-threaded, then the effects may be completely unexpected. If not, then I think everything will be fine. - pavel
  • The application is multithreaded. How can you control that at the moment of time everyone has the same instance of settings? - Sleeeper
  • on a vise - either a singleton, or a static class of settings and locks for access for thread safety, format: only one writes, the rest wait, read everything, while at least someone reads - the record waits. - rdorn

0