Oddzielanie logiki biznesowej od logiki DB przy transakcjach

11

architektura

W naszej aplikacji mamy trzy warstwy. Warstwa usługi zapewniająca zewnętrzny interfejs API. Warstwa BO dla naszej logiki biznesowej i warstwa DAO dla naszego połączenia z bazą danych.

Powiedzmy, że za każdym razem, gdy aktualizujemy plik, chcemy również coś zmienić w folderze, na przykład „data ostatniej modyfikacji”. Trzeba to zrobić w transakcji. Albo się powiedzie, a plik i folder są edytowane. Lub wystąpiła awaria i transakcja zostaje wycofana, więc oba obiekty są w poprzednim stanie.

Działanie „Edytuj folder podczas edycji pliku” jest logiką czysto biznesową. Oznaczałoby to, że należy do warstwy BO. Jednak używamy Objectify dla naszej bazy danych, więc aby rozpocząć transakcję, musimy wywołać ofy (). Transact (...). Jeśli wywołamy tę funkcję w warstwie BO, spowoduje to przerwanie naszego projektu, ponieważ w naszej warstwie biznesowej będą pojawiać się wywołania specyficzne dla bazy danych (Objectify).

Jakie byłoby czyste rozwiązanie tego problemu?

java design design-patterns transaction Serge Hendrickx
źródło
Nie możesz FileBOzadzwonić z FolderBO.edit(newDate)powodu problemu z transakcją?
Zauważył
czy Java nie ma odpowiednika c # TransactionScope?
Ewan
W Javie zakres transakcji zależy od używanej struktury. W JEE może być zarządzany przez serwer aplikacji, ale zwykle jest zdefiniowany i zarządzany deklaratywnie przez Varia Frameworks, takie jak Spring (vía adnotations, xml, ...)
Laiv
Nie martw się o próbę uczynienia różnych „warstw” aplikacji niezależnymi / nieświadomymi. Wciel się w pomysł, że twój kod jest zbudowany dla architektury, którą obsługuje, i zamiast tego skup się na tym, aby ten kod był dobrze skomponowany względem siebie.
Ant P

Odpowiedzi:

5

Sposób cięcia transakcji jest logiką biznesową. Pozwól więc, aby twoja warstwa DAO zapewniała niezależny od frameworku API interfejs API dla wspomnianej transactmetody (i prawdopodobnie dla rzeczy takich jak commiti rollback). Następnie możesz użyć go ze swojej warstwy BO bez uzależniania go od bazy danych lub środowiska db.

Doktor Brown
źródło
4

Wygląda na to, że Objectify jest przeznaczony do transakcji typu atomowego ( Google Application Engine Transactions ). Będzie wymagać od ciebie opracowania własnej abstrakcji zarządzania transakcjami .

W tym przypadku. abstrakcja trwa Jak delegować zarządzanie transakcjami do wyższych warstw?

Podejście @DocBrown wydaje mi się szybszym i czystszym rozwiązaniem do wdrożenia w danej architekturze ( architektura warstwowa ).

Ponieważ brakuje nam zbyt wielu informacji o aplikacji i jej kontekście, rozwiązanie Doc wydaje mi się również najbezpieczniejsze.

Proponuję jednak zajrzeć do wzorca projektowego UnitOfWork dla warstwy biznesowej . Myślę, że pasuje to do zarządzania transakcjami zaplanowanymi przez Objectify .

W skrócie, wzorzec ten ma na celu zawarcie reguł biznesowych w Transakcjach biznesowych (jednostkach pracy). Wzór pozwala na dziedziczenie między B.Ts i jak dotąd widzę, Objectify też. Obsługuje nawet kompozycję. Więc albo o składzie lub dziedziczenia, podejście umożliwia kompleksowe B.Ts .

Zastosowany do danej architektury wyglądałby następująco:

FileService -> FileBO : new EditFileTransaction().execute()
                           |-> ofy().transact(...)
                           |--> FileDAO.actionA()
                           |--> FolderDAO.actionA()
                           |-> [ofy().commit(...)|ofy().rollback()]
Laiv
źródło