Logika obsługi bazy

0

Mam pytanie odnośnie tzw dobrych praktyk programowania.

Mam taką średniej wielkości aplikację i stworzyłem klasę DBAccessor która to odpowiada za połączenia z bazą. Każda klasa jak chce coś wsadzić albo wysadzić z bazy to używa metod DBAccessora. Teraz pytanie za 100 punktów. Jak to ładniej zrobić: Czy każda zainteresowana klasa ma sobie robić swój obiekt DBAccessora czy może klasa Main ma go tworzyć (jednego) i przekazać innym klasom jako referencja?

Dodam że używam nhibernate, klasa DBAccessor raz robi sobie factory sesji i później przy każdym zapytaniu tworzy sesję i ją ubija.

0

Użyłbym któregoś z dostępnych DI/IoC (np. StructureMap) i zarejestrował obiekt jako singleton.

Przykład dla mojego DAO:

         StructureMapConfiguration.BuildInstancesOf<ICatalogDao>()
                .TheDefaultIs(Registry.Object(new CatalogDao(session)))
                .AsSingletons();

Dostęp do DAO z dowolnego miejsca:

ICatalogDao catalogDao = ObjectFactory.GetInstance<ICatalogDao>();
0

singleton dla obiektu dostepu do bazy danych moze okazac sie zlym pomyslem
szczegolnie jesli kilka operacji bedzie uzywalo tego samego polacznia rownoczesnie (watki)

dobrym rozwiazaniem byloby w momencie wykonywania operacji biznesowej (grupy operacji) stworzyc obiekt dostepu do bazy danych uzyc go do wszelkich operacji biznesowych i zamknac

jeszcze zalezy czy to bedzie aplikacjia web czy forms?
w web moza taki scenariusz zoorganizowac tak ze strona w OnInit tworzy taki accessor i otwiera polaczenie a na PreRender zamyka, a wszystkie operacje (na stronie i w kontrolkach) uzywaja tego accessora
w forms mozna miec inne podejscie, teoretycznie mozna otwierac zawsze nowe polaczenie, lub otwierac jedno na dluzej z uwzglednieniem odnawiania podczas zerwania (ale nie polecam takiego rozwiazania), raczej suregowal bym tez tworzyc polaczenie dla grupy operacji biznesowych (np. w obsludze przycisku wszystkie powinny uzyc tego samego polaczenia, ale na koniec zamykamy)

0

A gdyby stworzyć singleton, w którym wszystkie odwołania do bazy danych były synchroniczne i w ten sposób zabezpieczyć dostęp wielu wątków jednocześnie?

0

mozna, ale robisz sobie waskie gardlo, bo robisz kolejke zapytan, zamiast wysylac je do serwera, ktory zakladam ze w wersji produkcyjnej to nie werska express i spokonje obsluzy wiele jednoczesnych zapytan

0

Tylko w praktyce oznacza to i tak zakładanie kolejnych lock-ów, bo jak zapewnić spójność danych, gdy z jednego wątku ktoś modyfikuje stan tabeli a z innego odczytuje (lub również modyfikuje). Konsekwencją tego jest i tak konieczność blokowania dostępu do danych przed edycją.
Większość projektów, których kod przeglądałem wykorzystuje jedna singleton, pozostałe zaś przyjmuje strategie pessimistic/optimistic lock. Przy małych i średnich systemach nie ma sensu realizować tego w ten sposób, i singleton spokojnie spełni swoje zadanie wzorowo.

Mimo to, jeśli "patelnia" zdecyduje się na rozwiązanie z osobnymi sesjami to nadal widzę tu zastosowanie DI/IoC i uzyskiwanie instancji DBAccessor z dowolnego miejsca w kodzie (dostęp statyczny do ObjectFactory), co rozwiązuje jego problem.

0

do zapewnienia spojnosci danych nalezy uzyc transakcji, timestamp i odpowiedniego isolation level

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0