Czy umieścić logikę biznesową w Procedurze składowanej, czy nie?

21

Zawsze odbywa się debata na ten temat - „Czy logikę biznesową należy zastosować w procedurze składowanej, czy nie?”. Jeśli zdecydujemy się nie używać narzędzia ORM i nie umieszczać logiki biznesowej w procedurze przechowywanej, to gdzie powinniśmy umieścić logikę biznesową?

W moich poprzednich aplikacjach zawsze wolałem umieszczać całą logikę biznesową tylko w procedurach przechowywanych. Następnie z kodu .NET wywołuję te Procedury składowane za pomocą bloków aplikacji dostępu do danych. SQLHelper itp. Ale nie zawsze tak może być. Zrobiłem trochę googlingu, ale skończyło się na zamieszaniu .......

Wszelkie sugestie ...?

c# .net sql

— Pravin Patil
źródło

Jestem stronniczy -> Przechowywane procesy zawsze. Ale potem jestem stronniczy. Zapomnij o zwinnym programowaniu, smutna rzeczywistość jest taka, że w świecie biznesu zmiany zawsze zachodzą ad-hoc i muszą być dokonywane „natychmiast”. Procedury przechowywane pozwalają na to. To ratownik życia. Próba wprowadzenia takich zmian za pomocą bazy kodu nie byłaby możliwa.

— Darknight,

4

@Darknight, Zależy w dużej mierze od twojej platformy i architektury, aby złożyć takie oświadczenie. Nie rozumiem, dlaczego wdrożenie procedury przechowywanej w bazie danych jest o wiele mniej czasochłonne niż powiedzmy, wykonanie kompilacji i wdrożenie skryptu w celu zbudowania nowego pliku WAR, wdrożenia go i zrestartowania serwera aplikacji.

— wałek klonowy

7

Procedury składowane - septyczny zbiornik informatyki.

— Mongus Pong,

1

Procedury składowane - po prostu kolejne narzędzie jak każde inne.

— sam yi

15

Przyjąłbym pragmatyczne podejście - historycznie główna „korzyść” z utrzymania logiki biznesowej w przechowywanych procesach jest spowodowana wydajnością (architektura warstwy 2,5), podczas gdy podział logiki biznesowej na warstwę BLL (warstwa 3 / N) jest ogólnie czystszy od perspektywa konserwacji i łatwiejsza do przetestowania (Mock / Stub out dostęp do danych).

Biorąc jednak pod uwagę, że ORMS .NET z włączoną obsługą LINQ, takie jak LINQ2SQL, EF i NHibernate, tworzą teraz sparametryzowane zapytania SQL, w których można buforować plany zapytań, są zabezpieczone przed wstrzykiwaniem SQL itp., Zgaduję, że przejście do architektury warstwy 3 / N jest bardziej atrakcyjne niż kiedykolwiek, a większości SPROC (szczególnie tych zorientowanych na zapytania) można całkowicie uniknąć. Wzorce repozytoriów w .NET często ujawniają parametry drzewa wyrażeń IQueryable / accept, pozwalając na bezpieczny, ale elastyczny dostęp do twoich tabel. (Osobiście w architekturach typu SOA nie ujawniłbym IQueryable poza BLL, tzn. Twoje warstwy usług i prezentacji powinny działać z dobrze zdefiniowanym zestawem metod. Powodem jest to, że w przeciwnym razie nigdy nie możesz w pełni przetestować swojego systemu, a wygrałeś

Jednak w systemie o przyzwoitych rozmiarach zawsze będzie kilka wyjątków, w których naprawdę intensywny pod względem danych fragment kodu może nadal wymagać zapisania jako przechowywany procesor ze względu na wydajność. W takich przypadkach zatrzymałbym SPROC i ujawniłbym SPROC poprzez ORM, ale nadal ujawniałbym funkcję jako metodę tranzytową na twojej BLL.

— StuartLC
źródło

1

+1 dla łatwiejszego pisania testów jednostkowych w warstwie aplikacji, jednak zautomatyzowane ramy testowania jednostek DB przeszły długą drogę.

— wałek klonowy

14

Będąc programistą Java, wolałem umieścić logikę biznesową w BLL (miła i łatwa kontrola źródła, znajomość itp. Itd.).

Jednak po pracy w dużym przedsiębiorstwie z wieloma aplikacjami rozproszonymi korzystającymi z różnych technologii (C #, Java, Pick (nie pytaj)) stała się widoczna jedna znacząca korzyść z korzystania z procedur przechowywanych:

Procedury przechowywane mogą być współużytkowane przez różne aplikacje .

— Nim Chimpsky
źródło

Bardzo dobry punkt

— NoChance 10.10.11

1

Jest to bardzo prawdziwe i wykorzystujemy to, aby wywierać pozytywny wpływ w naszym środowisku. Jednak udostępnianie kodu przy użyciu warstwy danych zawsze wydawało mi się trochę niebezpieczne. Jeśli masz wielu konsumentów danego elementu logiki / danych, wolę postawić przed nim usługę, a nie wielu konsumentów tej samej bazy danych.

— RationalGeek,

2

Jeśli podzielisz zarządzanie danymi na biblioteki, biblioteki te mogą być również teoretycznie współużytkowane przez różne aplikacje ...

— glenatron 10.10.11

2

Częściowo się zgadzam. Wszystkie te technologie mają bezpośredni dostęp do bazy danych; więc używasz procedur przechowywanych, aby udostępniać im wspólny kod. Równie dobrze możesz rozwiązać ten sam problem, mając warstwę środkową i heterogeniczne rozwiązania uzyskują dostęp do warstwy środkowej zamiast do bazy danych, a ta warstwa środkowa dzieli taki kod.

— Ekevoo,

1

fyi ta odpowiedź jest baloney, 6 lat później - tylko dane trafiają do bazy danych. Umieszczasz tam logikę, masz wiele kłopotów. Wystarczy zbudować mikrousługę w wybranym języku, który uzyskuje dostęp do bazy danych.

— NimChimpsky

6

Nasz zespół ma tutaj łagodną zasadę. Czasami lepiej jest rozwiązać logikę biznesową w T-SQL, czasem łatwiej jest to zrobić w c # (warstwa biznesowa).

Mamy więc pragmatyczne rozwiązanie: postaw tam, gdzie lepiej pasuje. Wiem, że teoria jest czasem bardzo surowa ... ale taka jest teoria :-)

— gsharp
źródło

2

Czy to najgorsze rozwiązanie ze wszystkich? Skąd utrzymujący programista wie, gdzie jest przechowywana logika? Wyobrażam sobie, że czasami wkrada się również do warstwy aplikacji, a co gorsza, do interfejsu użytkownika?

— Paul T Davies,

2

Nie. Zawsze dotyczy warstwy biznesowej lub T-SQL. Ustalenie, gdzie jest przechowywana logika, jest prawdopodobnie najmniejszym problemem, jeśli chodzi o konserwację.

— gsharp,

Co się stanie, gdy ktoś dołączy do zespołu, a ty powiesz mu tę zasadę? Skąd mają wiedzieć, gdzie coś „pasuje lepiej”? Wydaje mi się, że to prawie żadna reguła. Bardzo subiektywny w oparciu o jednostkę.

— RationalGeek

3

Chodźcie chłopaki, poważnie? Zatrudniamy ludzi, którzy mają mózg do myślenia i mają trochę doświadczenia na pokładzie. Potem… och tak, mają usta, by zapytać i porozmawiać. Mogę powiedzieć, że nasze oprogramowanie wymaga bardzo niewielkiej konserwacji, a nowe funkcje mogą być dobrze wdrożone przez prawie wszystkich członków naszego zespołu. nie może być tak źle, co robimy.

— gsharp,

4

Naprawdę nie widzę sensu, aby niewłaściwie używać języka C # do rzeczy, które SQLServer może zrobić o wiele lepiej i odwrotnie.

— gsharp,

3

Są zarówno zalety, jak i wady (moim zdaniem):

Procedury składowane mogą stać się koszmarem, jeśli nie używasz jakiejś kontroli źródła SQL (czego nie ma wiele miejsc) i pracujesz nad nimi wielu programistów. Ktoś może zmienić procedurę przechowywaną i zapomnieć o aktualizacji kodu wywołującego tę procedurę, a zanim się zorientujesz, właśnie zbudowałeś i wdrożyłeś witrynę, która będzie generować nieobsługiwane wyjątki (niedopasowanie liczby parametrów itp.).

Z drugiej strony, procedury składowane pozwalają na szybsze usuwanie błędów w niektórych sytuacjach. Jeśli występuje błąd w procedurze przechowywanej, wystarczy go naprawić i gotowe. Poprawka błędu w ORM wymaga przebudowy. W zależności od procesu kompilacji może to być długotrwałe / irytujące.

— AndrewC
źródło

+1 za potrzebę kontroli źródła z przechowywanymi procesorami, jeśli zamierzasz je intensywnie wykorzystywać. Wiele DBA, z którymi pracowałem, jest bardzo odpornych na ten pomysł.

— RationalGeek

2

Zawsze umieszczamy naszą logikę biznesową w warstwie logiki biznesowej. Jeśli umieścisz go w procedurze przechowywanej, zostanie on utracony po zmianie RDBMS.

— šljaker
źródło

16

Ostatnią rzeczą, która się zmienia, jest RDBMS ;-)

— gsharp

Czy to oznacza, że ograniczasz procedurę składowaną do pobierania, aktualizowania i wstawiania danych ...?

— Pravin Patil

1

W każdym dużym systemie, jaki widziałem, w rzeczywistości baza danych jest systemem. Języki programowania stają się w tym momencie prawie nieistotne, jak tylko „front end” ..

— Darknight,

2

@gsharp, to nie zawsze jest prawdą. Możesz dodać kolejny RDBMS, taki jak Oracle, lub całkowicie zastąpić istniejący. Lub, w niektórych przypadkach, chcesz zastąpić dane rzeczywiste danymi zastępczymi.

— šljaker 10.10.11

2

@ šljaker oczywiście nie zawsze jest to prawda. Ale bardziej prawdopodobne jest, że program zmieni się (przeprojektowanie oprogramowania, nowe języki programowania itp.) Niż DB.

— gsharp,

2

„Logika biznesowa” jest nieco niejasnym terminem. Mam na myśli, że nie ma jednej definicji. Zasadą jest minimalizowanie komunikacji między poziomami, gdy jest to możliwe. Nie trzeba więc wysyłać pustej nazwy klienta na serwer, aby ją sprawdzić przed wstawieniem wiersza.

Zdarzają się przypadki, gdy reguła oparta jest na odczycie bazy danych. Załóżmy, że chcesz przelać pieniądze z konta 1 na konto 2. Musisz przeczytać oba konta, upewnić się, że są w dobrym stanie i że kwota na koncie 1 jest wystarczająca. W takim przypadku serwer jest lepszym kandydatem na tę regułę, ponieważ klient (tutaj BL) nie musi wydawać 3 wywołań do warstwy bazy danych dla tego procesu.

Oczywiście, jeśli potrzebujesz, aby twoje rozwiązanie było niezależne od bazy danych, wykonaj przechowywane procesy tylko dla CRUD (jeśli w ogóle są używane).

— Bez szans
źródło

1

Logika powinna zawsze znajdować się w BLL, ponieważ:

Można to właściwie przetestować
Gdy SQL 20XX staje się przestarzały i trzeba przejść do najnowszej wersji, nie trzeba przepisywać kodu.
Ludzie nie mają ochoty wprowadzać zmian w locie (co wydaje się być argumentem za SP)
Z mojego doświadczenia wynika, że SP jest największym punktem błędu programisty, szczególnie po kilku generacjach konserwacji / zmian.

Uważam, że powinno istnieć prawo, które mówi, że gdy SP ma więcej niż X linii, nie działa zgodnie z przeznaczeniem.

— Paul T. Davies
źródło

Co jest nie tak ze zmianami w locie? Jeśli w procedurze przechowywanej jest błąd i można go łatwo naprawić, napraw go. Jest to pozytywne, ponieważ oznacza, że nie musisz robić ponownego wydania czegoś trywialnego. Tak długo, jak ludzie nie zaczynają maskować błędów w kodzie przez zmianę procedur przechowywanych, nie widzę problemu.

— AndrewC,

Przez zmiany w locie mam na myśli rzeczy, które nie zostały przetestowane i nie podlegają formalnej procedurze wydania. I tak, zmiany sp w celu maskowania błędów kodu są czymś, co widziałem całkiem sporo.

— Paul T Davies,

0

Tworzymy warstwę usług, która zawiera całą naszą logikę biznesową zaimplementowaną w wybranym języku i używamy bazy danych tylko do zapytań. Takie podejście jest w pewnym stopniu przez nas obowiązkowe, ponieważ naszym celem jest tworzenie rozwiązań COTS do dostarczania aplikacji z różnymi implementacjami baz danych. W tych okolicznościach Hibernacja okazała się dla nas ratunkiem.

Myślę, że największą zaletą tego podejścia, oprócz przenośności bazy danych, jest to, że wszystkie odpowiedzi można znaleźć w jednym wyszukiwaniu.

Ponadto, pomimo niektórych odpowiedzi na forum, mam przyjaciela pracującego dla firmy ubezpieczeniowej Fortune 100, która dokonała 2 konwersji bazy danych w ciągu trzech lat, ponieważ baza danych dla firmy uległa zmianie.

— Thom
źródło

0

Z mojego ograniczonego doświadczenia wolę zachować integralność danych dzięki procedurom przechowywanym i innym funkcjom bazy danych. Na przykład, gdybym realizował transfer środków między dwoma kontami, napisałbym procedurę składowaną. Uważam, że warto używać wielu języków aplikacji.

— Kevin Cline
źródło