Decoupling Domain classes from Django Model Classes

Question

Skończyłem więc moją analizę OO i zaprojektowałem aplikację internetową, którą buduję, a teraz jestem w trakcie implementacji. Podjęto decyzje projektowe, aby wdrożyć system za pomocą Pythona i platformy Django do tworzenia stron internetowych.

Chcę rozpocząć wdrażanie niektórych z moich klas jednostek domeny, które wymagają trwałości. Wygląda na to, że Django miałoby mnie zaimplementować jako klasy dziedziczone z klasy modeli Django, aby użyć ORM Django do utrwalania. Wydaje się to jednak zbyt silne powiązanie między moimi jednostkami klasy a mechanizmem trwałości. Co się stanie, jeśli na pewnym etapie chcę zrezygnować z Django i użyć innej struktury programistycznej lub po prostu pozbyć się ORM Django? Teraz muszę ponownie napisać moje klasy encji domeny od zera.

Więc lepiej byłoby zaimplementować moje klasy domen jako samodzielne klasy Pythona, obejmując w nich całą logikę biznesową, a następnie użyć jakiegoś mechanizmu (wzorca projektowego, takiego jak most lub adapter lub ???), aby delegować pamięć trwałości te klasy domen do ORM Django, na przykład poprzez klasę modelu Django, która została odpowiednio skonfigurowana.

Czy ktoś ma sugestie, jak to zrobić? Z tego, co przeczytałem, wynika, że ​​ludzie po prostu implementują swoje klasy domenowe jako klasy odziedziczone z klasy modelu Django i mają logikę biznesową wymieszaną w tej klasie. Nie wydaje się to dobrym pomysłem na zmiany w dół, konserwację, ponowne wykorzystanie itp.

Answer 1

Cóż, sposobem na Django jest dziedziczenie z klas modelu podstawowego Django. To jest wzór "rekordu aktywnego". Twoje modele django będą miały wszystkie metody CRUD i zapytania wraz z logiką biznesową (jeśli zdecydujesz się dodać to oczywiście). Jest to postrzegane jako anty-wzór w świecie java, ale fajne jest to, że może przyspieszyć rozwój naprawdę bardzo szybko.

Answer 2

Czy możesz poważnie przewidzieć możliwość, że porzucisz Django ORM, ale zachowaj wszystko inne? Lub, że jeśli całkowicie porzuciłeś Django, to kodtwojego kodu będzie nadal obowiązywał?

Nie narzekasz, że jeśli porzucisz Django, będziesz musiał przepisać wszystkie szablony. Oczywiście, że tak, tego można się spodziewać. Dlaczego więc warstwa prezentacji jest powiązana z ramą, ale nie z warstwą trwałości?

Ten rodzaj wyprzedzającej analizy, której należy unikać. Django to narzędzie RAD i najlepiej nadaje się do szybkiego, iteracyjnego programowania. Mimo to jest w stanie zbudować potężne, długowieczne aplikacje, o czym będzie świadczyć wiele dużych firm. Ale to nie jest Java i nie jest "przedsiębiorcza", i nie jest ona szczególnie zgodna z zasadami OO. W świecie Pythona jest to funkcja, a nie błąd.

Answer 3

Nie musisz "przepisywać swoich modeli od zera", jeśli potrzebujesz innego mechanizmu utrwalania. Cały punkt systemu trwałości w stylu activerecord nakłada minimalne ograniczenia na klasy modeli i działa w dużej mierze transparentnie.

Jeśli naprawdę się martwisz, wyodrębnij dowolny kod, który opiera się na zapytaniach do własnych metod.

Answer 4

Myślę, że nie ma wdrożonego rozwiązania do oddzielania modeli Django i klas domen, przynajmniej ja nie znalazłem żadnego. W rzeczywistości jedyny ORM z takim rozłączeniem, jaki znam, istnieje tylko w świecie Smalltalk i nazywa się GLORP. Pozwala na utrzymanie modelu domeny w relacyjnej bazie danych bez konieczności modyfikowania klas domen. Obecnie próbuję wprowadzić podobne pomysły, aby oddzielić od Django ORM.Moja motywacja jest taka, że ​​obecne silne sprzężenie między tabelami DB i klasami domen źle wpływa na ewolucję oprogramowania. Opublikuję ponownie, jeśli się uda :)