Cześć,
Potrzebuję zrobić zmienną, która będzie mi przetrzymywała dane i będę mógł z tych danych korzystać w całym projekcie. Jeśli się da to jak to zrobić?
Pozdrawiam,
PS. żadne wstrzykiwania zależności nie wchodzą w grę, projekt jest tak skopany że nie idzie się w nim połapać (kod został konwertowany z innego języka)
poczytaj o singletonach
Albo utwórz jakąś klasę która będzie zawierała potrzebne dane, następnie używaj jej tam gdzie zajdzie potrzeba. Niekoniecznie musi to być singleton.
Na sztywno danych też nie mogę przypisać bo będą się zmieniać więc pewnie singleton. Tylko pytanie czy mogę go użyć jeśli aplikacja składa się z wielu projektów i mogę te dane dzielić między nimi?
Gubię się. Chodzi Ci o mikroserwisy czy o kilka modułów w jednym projekcie?
Jeśli chodzi o "zmienną, która będzie mi przetrzymywała dane i będę mógł z tych danych korzystać w całym projekcie", to singleton się nada.
Jeśli natomiast nie chcesz jej mieć dostępnej w "całym projekcie" no to musisz wykombinować coś innego.
Nie wiem co to za zmienna, jeśli jakiś primitive i tylko jeden to może zwykły static wystarczy w odpowiednim miejscu.
Singleton albo klasa statyczna. A co dokładnie potrzebujesz? Czy to ma być jedna zmienna globalna, czy może szereg takich zmiennych?
Po co komu singleton skoro są klasy statyczne.
Po co komu singleton skoro są klasy statyczne
Jak to po co. over engineering.
Jak @Azarien pisze
np.
public static class ConfigStaticClassVisibleInWholeProjectInsteadSingleton
{
public static string PublicStaticVariableVisibleInWholeProject {get; set;}
}
Azarien napisał(a):
Po co komu singleton skoro są klasy statyczne.
Singletony są o niebo prostsze i o niebo bardziej skalowane zwłaszcza jeśli muszą przechowywać jakieś dane. Static'ki do czegoś innego niż utility i proste funkcje to płacz i zgrzytanie zębów.
@topik92: Ale temat dotyczy zmiennej przechowującej dane. Singleton o "niebo" prostszy? Niż 4 linijki kodu?
Przecież napisałem że do przechowywania danych jest lepszy, nie rozumiem o co Ci chodzi.
4 linijki są potrzebne by przerobić pragmatycznie dowolną klasę na singleton i wszytko można robić normalnie.
Przerobienie klasy na klasę statyczną już takie proste nie jest. Do tego nie można stosować w nich polimorfizmu, dziedziczenia i interfejsów, nie można ich tez przekazywać jako parametr, lub zapisać jako obiekt. Wymusza programowanie pisanie ich implementacji w sposób strukturalny. Ich inicjalizacja dla nie trywialnych przypadków to jeden wielki ból głowy. Dopisywanie nowych przypadków i synchronizacja danych tez jest straszna.
@topik92:
Spoko, wyluzuj. W pytaniu nie chodziło o przerobienie czegokolwiek na cokolwiek. Ani o dziedziczenie, interfejsy, nowe przypadki, przekazywanie jako parametry i cokolwiek innego tyko o proste udostępnienie zmiennej w całym projekcie. Ja mam czasem dokładnie takie przypadki jak w pytaniu. Używam do określenia czy aplikacja jest w trybie demo, żeby uruchomić symulatory pomiarów i procesów i static jest w sam raz.
No ja bym nigdy nie użył static, bo to jest wprowadzanie kupy do projektu. Potem ludzie zaczną tam dodawać więcej pól i metod, bo "są potrzebne w każdym miejscu aplikacji" i wyjdzie z tego taki GlobalSpaghettiManager.
A już tam. Jeżeli trzeba szybko wysterować czymś, co w samej swojej idei ma być na sztywno zaszyte w kodzie, to nie widzę absolutnie nic złego w tym, żeby utworzyć jakąś klasę Global i trzymać tam np rzeczy typu adres webserwisu, który ma być wbity na stałe i niedostępny do zmiany przez użytkownika aplikacji.
Dyskusyjne jest za trzymanie tam zmiennych, które mają być dostępne w całym programie. Jedni krzyczą, że to zuo (tak jak @somekind ), inni mówią że to dobre, chociaż ja bardziej skłaniam się ku poglądowi, że jeśli istnieje potrzeba takiego "Global.cs" ze statycznymi zmiennymi, to znaczy ze architektura projektu nie jest najwyższych lotów
Ja używam na co dzień Autofac i rejestruję tego typu obiekty jako SingleInstance. Dla mnie to jest najlepsze rozwiązanie.
Ja gdzieś kiedyś zrobiłem tak trzymając pewne rzeczy w XMLu
public static class Tools
{
private static string _plikKonfiguracji = HttpContext.Current.Server.MapPath("/ProjectName") + "/App_Data/CpzssKonfiguracja.xml";
private static Dictionary<XName, string> _konfiguracja;
private static void LoadKonfiguracja()
{
_konfiguracja = XDocument.Load(_plikKonfiguracji).Root
.Elements()
.ToDictionary(e => e.Name, e => (string)e);
}
public static Dictionary<XName, string> Konfiguracja
{
get
{
if (_konfiguracja == null)
{
LoadKonfiguracja();
}
return _konfiguracja;
}
}
public static void SetElementKonfiguracja(XName tagName, string tagValue)
{
var doc = XDocument.Load(_plikKonfiguracji);
doc.Root.SetElementValue(tagName, tagValue);
doc.Save(_plikKonfiguracji);
}
}
żadne wstrzykiwania zależności nie wchodzą w grę
Żeby korzystać z dobrodziejstw IoC wcale nie trzeba do tego wykorzystywać wstrzykiwania zależności. Wiadomo, że tak jest najprościej ale kontenery potrafią zrobić Resolve'a odpowiedniej klasy w każdym momencie, na żądanie. No chyba, że zastosowanie IoC też odpada.
Nie znam założen, ale czasem lepsza alternatywa dla popularnego "wzorca" singleton jest monostate.
Pawel
jacek.placek napisał(a):
@topik92:
Spoko, wyluzuj. W pytaniu nie chodziło o przerobienie czegokolwiek na cokolwiek. Ani o dziedziczenie, interfejsy, nowe przypadki, przekazywanie jako parametry i cokolwiek innego tyko o proste udostępnienie zmiennej w całym projekcie. Ja mam czasem dokładnie takie przypadki jak w pytaniu. Używam do określenia czy aplikacja jest w trybie demo, żeby uruchomić symulatory pomiarów i procesów i static jest w sam raz.
Po pierwsze to jestem spokojny, po drugie odpowiadałem na że Ty i @Azarien twierdzicie że singleton to jest skomplikowany w stosunku do staticków, po trzecie w pytaniu jest mowa o jakiś danych które się zmieniają. Co znaczy wszystko i nic może wiec nie wiem jakim cudem masz dokładnie takie przypadki.