Czy procedury składowane naruszają separację trójwarstwową?

Niektórzy z moich kolegów powiedzieli mi, że logika biznesowa w procedurach przechowywanych w bazie danych narusza trójdzielną architekturę separacji, ponieważ baza danych należy do warstwy danych, podczas gdy procedury przechowywane są logiką biznesową.

Myślę, że świat byłby bardzo ponurym miejscem bez przechowywanych procedur.

Czy naprawdę naruszają trzypoziomową separację?

Twoi koledzy łączą architekturę z implementacją.

Idea wielopoziomowej aplikacji polega na tym, że jest ona podzielona na części, które obejmują niektóre rodzaje przetwarzania (pamięć, logika biznesowa, prezentacja) i komunikują się ze sobą za pomocą dobrze zdefiniowanych interfejsów. Tak jak z powodzeniem można robić rzeczy, które przypominają programowanie obiektowe w językach innych niż obiektowe, tak samo można robić to samo z wieloma warstwami w jednym środowisku, na przykład z serwerem bazy danych. To, co łączy jedną z tych osób z powodzeniem, to potrzeba opieki, dyscypliny i zrozumienia związanych z tym kompromisów.

Spójrzmy na trójwarstwową aplikację, w której dwie warstwy zostały zaimplementowane w bazie danych:

• Poziom danych: składa się z tabel baz danych dostępnych za pomocą czterech standardowych operacji tabeli ( INSERT, UPDATE, DELETEi SELECT).
• Warstwa logiczna: składa się z procedur przechowywanych, które implementują tylko logikę biznesową i uzyskują dostęp do warstwy danych przy użyciu tylko metod opisanych powyżej.
• Poziom prezentacji: składa się z serwera WWW z uruchomionym kodem, który uzyskuje dostęp do warstwy logicznej, wykonując tylko wywołania procedur składowanych.

Jest to całkowicie akceptowalny model, ale ma pewne kompromisy. Logika biznesowa jest zaimplementowana w sposób, który zapewnia szybki i łatwy dostęp do warstwy danych i może pozwolić na robienie rzeczy, które musiałyby być wykonane „na twardo” przez warstwę logiki poza bazą danych. To, czego się poddajesz, to możliwość łatwego przeniesienia jednej z warstw do innej technologii i bezproblemowe wdrożenie (tj. Musisz zachować szczególną ostrożność, aby warstwy nie korzystały z udogodnień dostępnych w bazie danych, ale poza zdefiniowanymi interfejsami) .

To, czy tego rodzaju rzeczy i wynikające z nich kompromisy są dopuszczalne w danej sytuacji, jest czymś, co ty i twoi koledzy musicie ustalić na podstawie własnego osądu.

Procedury przechowywane są na tyle potężne, że pozwalają zakodować naruszenie trzypoziomowej separacji poprzez wprowadzenie logiki biznesowej do warstwy RDBMS. Jest to jednak twoja decyzja, a nie nieodłączna wada procedur przechowywanych. Możesz ograniczyć swoje SP do obsługi potrzeb twojej warstwy danych, zachowując logikę aplikacji w warstwie aplikacji twojej architektury.

Istnieje rzadki, ale ważny wyjątek od reguły separacji, gdy potrzebne są procedury składowane (w szczególności grupa wyzwalaczy) do zawarcia logiki biznesowej. Dzieje się tak, gdy aplikacja musi generować wiele agregacji danych w locie, które dotykają milionów wierszy. W takich przypadkach można skonfigurować wyzwalacze, aby zachować wstępnie zagregowane dane na potrzeby korzystania z warstwy biznesowej. Należy to zrobić tylko w sytuacjach, gdy bez wstępnej agregacji aplikacja byłaby niedopuszczalnie wolna.

Porady Atwooda z 2004 roku są prawdziwe do dziś, tylko teraz mamy również korzyści z ORM.

http://blog.codinghorror.com/who-needs-stored-procedures-anyways/

Procedury składowane należy uznać za język asemblera bazy danych: do użycia tylko w sytuacjach krytycznych pod względem wydajności. Istnieje wiele sposobów zaprojektowania solidnej, wysokowydajnej warstwy dostępu do danych bez uciekania się do procedur przechowywanych; uzyskasz wiele korzyści, jeśli będziesz trzymał się sparametryzowanego SQL i jednego spójnego środowiska programistycznego.

Krótkie streszczenie: To naprawdę zależy od korzystania z procedur przechowywanych i wymagań biznesowych.

Istnieje wiele projektów wykorzystujących architekturę trójwarstwową, w zależności od charakteru wymagań biznesowych może zaistnieć potrzeba przeniesienia niektórych operacji na warstwę danych.

Mówiąc o terminologii, ogólnie mówiąc, poziomy te opisane są jako:

• Warstwa prezentacji lub warstwa usług użytkownika - daje użytkownikowi dostęp do aplikacji.
• Warstwa środkowa lub warstwa usług biznesowych - składa się z reguł biznesowych i danych.
• Warstwa danych lub warstwa usług danych - współdziała z trwałymi danymi zwykle przechowywanymi w bazie danych lub w pamięci stałej.

Zwykle dla danej architektury warstwa środkowa lub warstwa usług biznesowych składa się z reguł biznesowych i danych. Czasami jednak duże znaczenie ma przesunięcie ciężkich operacji bazowych i / lub reguł danych, które należy wykonać w warstwie danych - poprzez zestaw procedur przechowywanych.

Zalety trójwarstwowych konstrukcji to:

Podczas cyklu życia aplikacji podejście trójwarstwowe zapewnia takie korzyści, jak możliwość ponownego użycia, elastyczność, łatwość zarządzania, łatwość konserwacji i skalowalność. Możesz współdzielić i ponownie wykorzystywać utworzone przez siebie komponenty i usługi, a także dystrybuować je w sieci komputerów w razie potrzeby. Możesz podzielić duże i złożone projekty na prostsze i przypisać je różnym programistom lub zespołom programistycznym. Możesz także wdrożyć komponenty i usługi na serwerze, aby nadążyć za zmianami, i możesz je ponownie wdrożyć w miarę wzrostu bazy użytkowników aplikacji, danych i wolumenu transakcji.

Dlatego tak naprawdę jest to podejście oparte na analizie przypadków, które samo w sobie ma kompromisy. Jednak wytyczne projektowe Microsoft trójwarstwowego modelu architektury zalecają utrzymanie logiki biznesowej na środkowym poziomie.

Poziom faktycznie oznacza inną maszynę, warstwa oznacza inną logiczną separację. Dzięki procedurom przechowywanym warstwa danych i (przynajmniej część) warstwa logiki biznesowej znajdują się w tej samej warstwie. Umieszczenie logiki biznesowej w procedurach przechowywanych narusza architekturę 3-zmęczoną, ale jest wątpliwe, czy narusza architekturę 3-warstwową; jedną pewną rzeczą jest to, że z pewnością nie jest to dobry przykład rozdzielenia obaw.

Warstwa jest logicznym mechanizmem strukturyzacji elementów tworzących oprogramowanie; warstwa jest fizycznym mechanizmem strukturyzacji infrastruktury systemu. ( Odniesienie )

Moim zdaniem istnieją dwa główne problemy z budowaniem logiki biznesowej w bazie danych:

1. Kod i biblioteki: mniej programistów będzie w stanie programować w SQL, PL / SQL, TSQL itp. Niż w C #, Java itp. Języki programowania mają również tę zaletę, że mają świetne IDE, świetne biblioteki i frameworki.

2. Skalowalność w poziomie: jedynym sposobem na skalowanie systemu jest zmiana fizycznego serwera, na którym baza danych jest mocniejsza, co jest dość drogie (serwer z 64 GB pamięci RAM); relacyjne bazy danych skalują się w poziomie bardzo źle, a nawet przy większych wydatkach. Natomiast dzięki logice biznesowej na serwerze zbudowanym z OO można całkiem dobrze skalować w poziomie, umieszczając serwer na wielu węzłach (w Javie wiele serwerów aplikacji to obsługuje).

Mieliśmy tę debatę w naszym biurze jakiś czas temu, opowiadałem się za rozwojem baz danych, mam na to pogląd

1. Jeśli korzystasz z bazy danych Oracle, powinieneś w jak największym stopniu korzystać z PL / SQL, ponieważ na pewno firmy, które inwestują, będą trzymać się wyroczni przez co najmniej 10 lat. Podczas gdy wczoraj w aplikacjach korzystałeś z formularzy Oracle Forms, dziś formularzy .net Web, następnie MVC, a jutro będziesz używać angularjs i potrzebujesz tylko spokojnych apis. Jeśli masz maksymalną logikę w bazie danych, możesz łatwo migrować do nowych technologii frontonu.
2. Tworzenie baz danych jest bardzo szybkie i bardzo wydajne pod względem wydajności. Żeby dać ci perspektywę. W naszym projekcie było 7 programistów aplikacji i jeden programista baz danych, a 80% logiki było w bazie danych.
3. Jeśli używasz Oracle, możesz użyć narzędzi do bezpośredniego przekształcenia procedur bazy danych w Res Full Api.

Najsilniejszy argument, który twórcy aplikacji podają, że logika biznesowa powinna być niezależna od bazy danych, aby można ją było łatwo zmienić. Myślę, że jeśli firma korzysta z Oracle, dlaczego zamiast tego przestawi się na inną technologię, bardziej spodziewane są szanse na utratę logiki aplikacji. Problem polega głównie na tym, że brakuje nowych talentów zasobów bazy danych, głównie faceci zaczną proste strony internetowe, na których używają mysql lub sqlserver. Ci faceci stają się następnie starszymi leadami i mają emocjonalne przywiązanie do warstwy aplikacji :) nawet nie chcą rozumieć ani debatować.