modele django = logika biznesowa + dostęp do danych? Lub warstwę dostępu do danych należy oddzielić od modelu django?

W Django sugerowana architektura oprogramowania polega na umieszczeniu logiki biznesowej i dostępu do danych w modelach.modele django = logika biznesowa + dostęp do danych? Lub warstwę dostępu do danych należy oddzielić od modelu django?

Jednak niektórzy współpracownicy sugerowali, że warstwa dostępu do danych powinna być oddzielona od logiki biznesowej (warstwa usług biznesowych). Ich uzasadnieniem jest to, że warstwa dostępu do danych może izolować zmiany, jeśli używane jest inne źródło danych. Mówią też, że istnieje logika biznesowa, która może występować w więcej niż jednym modelu.

Ale kiedy zaczynam kodowanie przy użyciu osobnych warstw dostępu do danych i logiki biznesowej, warstwa dostępu do danych jest prosta (w zasadzie kod modelu, który definiuje schemat bazy danych) i nie wydaje się dodawać wiele wartości.

Czy naprawdę warto oddzielić dostęp do danych od modeli django, czy django zapewnia już wystarczającą warstwę dostępu do danych za pomocą ORM?

Poszukuję programistów, którzy wdrożyli sporą liczbę aplikacji django i zobaczą, jaka jest ich opinia. Dotyczy to małej i średniej wielkości aplikacji internetowej.

Źródło

2012-01-18 TaiwanGrapefruitTea

Warstwa dostępu do danych to ORM. ** jest ** oddzielone od modelu. Nie zmienisz ORM-ów. ** ** zmienisz silniki baz danych; i jest to już zrobione trywialnie przez warstwę ORM. Nie jest jasne, co twoi koledzy rozumieją przez "warstwę dostępu do danych". Czy możesz podać więcej informacji? –

możliwy duplikat [Rozdzielenie logiki biznesowej i dostępu do danych w django] (http://stackoverflow.com/questions/12578908/separation-of-business-logic-and-data-access-in-django) –

@the_drow: OT: czy możesz przestać sprawdzać robo i zwracać uwagę na zmiany? [Ta sugerowana edycja] (http://stackoverflow.com/review/suggested-edits/3992632) była oczywistym komentarzem, a nie sugerowaną zmianą, która powinna zostać zaakceptowana. –

Po trzech latach rozwoju Django nauczyłem się następujących rzeczy.

ORM jest warstwą dostępu. Nic więcej nie jest potrzebne.

50% logiki biznesowej zostaje uwzględnione w modelu. Niektóre z nich powtarza się lub wzmacnia w formularzach.

20% logiki biznesowej znajduje się w Formularzach. Na przykład wszystkie walidacje danych znajdują się w formularzach. W niektórych przypadkach formularze zawężą ogólną domenę (dozwoloną w modelu) do pewnego podzbioru, który jest specyficzny dla problemu, firmy lub branży.

20% logiki biznesowej kończy się w innych modułach aplikacji. Te moduły znajdują się nad modelami i formularzami, ale pod funkcjami widoku, RESTful usług internetowych i aplikacji wiersza polecenia.

10% logiki biznesowej kończy się w aplikacjach uruchamianych z wiersza poleceń za pomocą interfejsu poleceń zarządzania. Jest to ładowanie plików, wyciągi i losowe zmiany zbiorcze.

Bardzo ważne jest, aby funkcje przeglądania i usługi RESTful nie działały w przybliżeniu. Używają modeli, formularzy i innych modułów w jak największym stopniu. Funkcje widoku i usługi sieciowe RESTful są ograniczone do obsługi kaprysów HTTP i różnych formatów danych (JSON, HTML, XML, YAML, cokolwiek innego).

Próba wymyślenia Jeszcze inna warstwa dostępu jest ćwiczeniem o zerowej wartości .

Źródło

2012-01-18 16:33:07

kilka doskonałych szczegółów na temat bardziej konkretnej architektury dla django: http://stackoverflow.com/questions/12578908/separation-of-business-logic-and-data-access-in-django?rq=1 – TaiwanGrapefruitTea

Nie zgadzam się, że ORM jest warstwą dostępu do danych; ORM zawiera * najwięcej * warstwy dostępu do danych. Używanie ORM bezpośrednio w modelach i kojarzenie tabel bazy danych z atrybutami modelu powoduje powiązanie aplikacji z relacyjnymi bazami danych i konkretną ORM (np. Django). Jest to nieodłącznie związane z wzorcem aktywnego rekordu, którego używa Django (https://docs.djangoproject.com/en/dev/misc/design-philosophies/). Jeśli chcesz odłączyć logikę biznesową i dostęp do danych, powinieneś zamiast tego użyć wzorca projektowego odwzorowania danych (np. SQLAlchemy ORM obsługuje to). To może być jednak przesada w przypadku niektórych aplikacji. –

Odpowiedź zależy od wymagań aplikacji.

W przypadku aplikacji, które zawsze będą korzystać z relacyjnych baz danych i można je połączyć z określoną usługą ORM, nie ma potrzeby oddzielania dostępu do danych i modeli. Django ORM opiera się na schemacie projektowania aktywnego rekordu, który zakłada, że dostęp do danych i model są ze sobą powiązane. Pro to prostota, con to mniejsza elastyczność.

Oddzielenie dostępu do danych i modelu jest konieczne tylko wtedy, gdy programista chce odłączyć całkowicie warstwę dostępu do danych i logikę biznesową. Możesz to zrobić za pomocą wzorca projektowego odwzorowania danych. Niektóre ORM obsługują ten wzorzec projektowania, taki jak SQLAlchemy. Pro to większa elastyczność, con jest bardziej złożona.

Polecam książkę "Patterns of Enterprise Application Architecture" autorstwa Martina Fowlera po więcej szczegółów.

Źródło

2014-12-01 13:08:06

modele django = logika biznesowa + dostęp do danych? Lub warstwę dostępu do danych należy oddzielić od modelu django?

Odpowiedz

Powiązane problemy