Najlepsze praktyki: wzorce programowania aplikacji bazodanowych


11

Do tej pory napisałem wiele aplikacji internetowych baz danych (MySQL), ale zawsze uważam, że moja struktura jest trochę niezdarna. Chcę poprawić wzorce programowania / projektowania, których używam, mając nadzieję na kilka porad tutaj. W szczególności nie mogę znaleźć struktury, która uzupełniałaby podejście OOP, które zawiera implementację bazy danych (schemat). ja

Pomyśl, że moje pytanie najlepiej wyjaśnić na przykładzie. Teraz używam 2 podejść, że mam obiekt / klasę faktury:

pierwszym jest użycie statycznych funkcji składowych

class Invoice
{
   int id;
   string ref;
   int customer_id;
   date created;
   date due;

   static id create();
   static bool update(id, field1, field2, ...);
   static bool delete(id);
   static bool get(id);
};

Drugie podejście polega na umieszczeniu wszystkiego w obiekcie bazy danych:

class Database extends ProprietaryDBConnecter, Singleton
{
   id createInvoice();
   bool updateInvoice(id, field1, field2, ...);
   bool deleteInvoice(id);
   bool getInvoice(id);

   id createCustomer();
   bool updateCustomer(id, field1, field2, ...);
   bool deleteCustomer(id);
   bool getCustomer(id);

   // etc...
}

Uważam, że w obie strony funkcje składowe (SQL) są bardzo nierozdzielne od „widoku”, ponieważ „widok” określa, co klasy muszą mieć, a zatem wydaje się, że psuje architekturę dokumentu / widoku.

Wydaje się również, że jest to trochę nieefektywne, na przykład instrukcja SELECT powinna tylko wybierać to, co jest potrzebne, ale obecność zmiennych składowych na fakturze wydaje się sugerować „dane gwarantowane”.

Nie wiem, czy jasno wyjaśniłem pytanie: Jakie są inne najlepsze podejścia do tej architektury / wzorca projektowego / co to jest znane?

Dziękuję za porady

Odpowiedzi:


14

Przypuszczam, że możesz użyć ORM.

Ale tak naprawdę, projektowanie baz danych NIE powinno być zgodne z założeniami OOP, powinno być zgodne z założeniami dotyczącymi projektowania baz danych, takimi jak normalizacja. I powinien być zaprojektowany w bazie danych, a nie w aplikacji. Reguły integralności danych powinny być egzekwowane na poziomie bazy danych, a nie przez aplikację.

Sugeruję przeczytanie kilku książek o projektowaniu baz danych, a następnie przeczytanie o dostosowywaniu wydajności wybranej bazy danych.


5
+1 za nie wszystko musi być OOP (nawet jeśli niektóre ORM są całkiem fajne!)
Javier

1
O / RM są dobre, ale korzystanie z nich nie oznacza, że ​​nie możesz dostosować się do dobrego projektu bazy danych.
BlackICE,

1
@David, zgadzam się, że to prawda w rękach kogoś, kto wie, co robi. I zasugerowałem, aby spojrzał na ORM, ale tak naprawdę, jeśli nie znasz najpierw projektu bazy danych, ORM jest niebezpiecznym narzędziem.
HLGEM,

To dobrze, że reguły integralności danych można egzekwować na poziomie bazy danych. Czasami jednak sensowne jest umieszczenie w aplikacji niektórych reguł (takich jak „projekt musi zawsze zawierać więcej niż 5 członków zespołu”), jeśli reguły mogą ulec zmianie, a tylko aplikacja będzie modyfikować dane.
Jon Onstott,

Aplikacja prawie nigdy nie jest jedyną rzeczą, która modyfikuje dane. Reguły biznesowe, które nie są wprowadzane do bazy danych, są bardzo łatwo łamane, gdy ktoś musi dokonać szybkiej zmiany dużej części danych w celu obsługi poprawki danych.
HLGEM,

10

Nie mogę znaleźć struktury, która uzupełnia podejście OOP, które zawiera implementację bazy danych

Wygląda na to, że opisujesz niedopasowanie impedancji relacyjnej względem obiektu .

Jest wiele rzeczy, które powinny rozwiązać ten OODBMS, narzędzia ORM, szereg narzędzi dostępu do danych.

Myślę, że fakt, że istnieje tak wiele rozwiązań, prowadzi mnie do wniosku, że One True Solution ™ nie istnieje.

Możesz więc wybrać dowolny kierunek, który ci się podoba, wiedząc, że niektórzy będą go nienawidzić, a niektórzy go pokochają.


Wygląda na to, że jest bardziej rygorystyczny.
Jake

2

Jeśli nie chcesz używać opakowania ORM, skorzystaj z bazy danych obsługującej pamięć w stylu OOP, np . MongoDB .

MongoDB (od „hu Mongo nas”) jest wieloplatformowym bazie dokument zorientowanych systemu. Sklasyfikowana jako baza danych „ NoSQL ”, MongoDB unika tradycyjnej relacyjnej struktury baz danych opartej na tabeli na rzecz dokumentów podobnych do JSON z dynamicznymi schematami (MongoDB wywołuje format BSON ), dzięki czemu integracja danych w niektórych typach aplikacji jest łatwiejsza i szybsza. ..

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.