t-sql/c# wzorce projektowe

0

Jakie się standardowo stosuje wzorce projektowe aby właściwie rozdzielać kod. Czyli która cześć powinna być implementowania po stronie bazy (np. t-sql) a która po stronie aplikacji (np. c#).

Pozdrawiam,
Zoritt

0

Chyba użycie pojęcia wzorca projektowego jest tu niewłaściwe. Bo wzorce opisują coś innego niż podział na tzw. warstwy.
Nadrzędną zasadą aplikacji wielowarstwowych jest to aby warstwy można było stosunkowo niezależnie rozwijać. Nie jest nigdzie powiedziane że architektura trójwarstwowa jest jedyna i najlepsza.
Więc na twoje pytanie nie ma dobrej odpowiedzi.

System implementowany w języku obiektowym, z obiektowym modelem danych, najczęściej próbuje użyć bazy jedynie jako magazyn danych. A cała logika jest po stronie warstwy biznesowej, w obiektach.
Z doświadczenia - utrzymanie systemów gdzie duża część logiki jest po stronie bazy jest trudniejsze, wymaga także większej wiedzy o bazach danych.
Jednak jeśli interfejs (GUI) jest generyczny, to odpowiednio duża część logiki po stronie bazy umożliwia rozwój systemu bez zmian w kodzie aplikacji. I takie coś też na oczy widziałem i działało dopóki jakiś jeden klient nie zaczął zbytnio świrować. Ale dalej nie zmieniany był tzw. core, tylko dopisane wtyczki.
W dobie kiedy popularność zdobywają OR mappery idzie się w kierunku użycia bazy właśnie jako magazynu danych (relacyjnych), ale jednak magazynu, a logikę umieszcza w kodzie. Oczywiście pojawiają się skomplikowane obliczenia na danych (np. raporty), które wymagają skomplikowanych zapytań sql, bo zwyczajnie w kodzie byłyby niewydajne.
Oczywiście umieszczenie części logiki na bazie (procedury składowane) i umiejętne użycie może podnieść wydajność systemu.

Można by tak długo się rozpisywać kiedy tak, kiedy siak. Jakie są plusy, jakie minusy. Ale w IT raz, że rozwiązań jednego problemu często jest wiele (i ciężko jednoznacznie odpowiedzieć które lepsze), a dwa że wszystko zależy od konkretnego przypadku. Ogólne teoretyzowanie to domena uczelni.

0

OK. Dziękuje za odpowiedź.
Napisz mi proszę co w sytuacji w której mamy zagrożenie integralności danych. Np. rekord w tabela1 osiąga stan 2 co oznacza, że musi zostać dodany rekord do tabeli2 z jednoczesnym założeniem, że przy stanie 1 (dla rekordu w tabeli1) rekord ten musi zostać usunięty. Jeżeli dodawania i usuwanie tego rekordu zlecę aplikacji "A" to istnieje duże zagrożenie, że aplikacja "B" nie zachowa tego warunku. W przypadku umieszczenia tego warunku na serwerze SQL każda aplikacja zmieniająca stan rekordu z tabeli1 wyzwoli obsługę tabeli2.
Szukam dobrych wzorców do najwłaściwszych rozwiązań.

Pozdrawiam,
Zoritt

1

Jeśli umożliwiasz wielu aplikacjom, na które nie masz wpływu operować bezpośrednio na bazie danych, to oczywiście powinieneś na poziomie bazy zapewnić odpowiednie mechanizmy. Dostęp przez procedury składowane, triggery, constrainty.
Jeśli jesteś w stanie odgrodzić się jakąś dodatkową warstwą - udostępnić dll z DAL (warstwa dostępu do danych), warstwę webservice etc., to problem się rozwiąże, bo po stronie kodu możesz mieć taką logikę. Oczywiście w tedy kilka zapytań należy uruchamiać w transakcji, ta sama uwaga przy bardziej skomplikowanej logice np. w procedurze składowanej.

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