To stare pytanie, ale napotykając je, nie sądzę, aby przyjęta odpowiedź odpowiadała na pytanie. Pytanie nie brzmiało:„Co to jest MongoEngine?” - było "Dlaczego powinienem używać MongoEngine?" I zalety takiego podejścia. Wykracza to poza Django do Pythona/Mongo w ogóle. Moje dwa centy:
Podczas gdy zarówno PyMongo, jak i MongoEngine zwracają obiekty (co nie jest złe), PyMongo zwraca słowniki, do których klucze muszą się odwoływać za pomocą ciągu znaków. MongoEngine umożliwia zdefiniowanie schematu za pomocą klas dla danych dokumentu. Następnie zmapuje dokumenty do tych klas i pozwoli ci nimi manipulować. Po co definiować schemat dla danych bez schematu? Ponieważ moim zdaniem jest to jasne, jednoznaczne i znacznie łatwiejsze do zaprogramowania. Nie kończysz ze słownikami rozproszonymi po całym kodzie, w których nie możesz stwierdzić, co się w nich znajduje, bez rzeczywistego przeglądania danych lub uruchamiania programu. W przypadku MongoEngine i przyzwoitego IDE jak PyCharm, wpisanie prostego "." po tym, jak obiekt powie ci wszystko, co musisz wiedzieć, poprzez autouzupełnianie. Innym programistom, którzy przychodzą, jest również znacznie łatwiej badać i uczyć się modelu danych podczas pracy i sprawić, że każdy, kto nie widział kodu od jakiegoś czasu, będzie bardziej produktywny i szybszy.
Dodatkowo, według mnie, składnia używana do manipulowania dokumentami za pomocą PyMongo (która jest zasadniczo taka sama jak konsola mongo) jest brzydka, podatna na błędy i trudna w utrzymaniu.
Oto podstawowy przykład aktualizacji dokumentu w MongoEngine, który dla mnie jest bardzo elegancki:
BlogPost.objects(id=post.id).update(title='Example Post')
Dlaczego warto korzystać z PyMongo? MongoEngine jest warstwą między tobą a gołym metalem, więc prawdopodobnie jest wolniejszy, chociaż nie mam żadnych benchmarków. PyMongo jest niższym poziomem, więc naturalnie masz większą kontrolę. W przypadku prostych projektów MongoEngine może być niepotrzebny. Jeśli jesteś już biegły w składni Mongo, możesz uznać, że PyMongo jest znacznie bardziej intuicyjny niż ja i nie będziesz miał problemu z pisaniem złożonych zapytań i aktualizacji. Być może lubisz pracować bezpośrednio ze słownikami na tym niższym poziomie i nie interesuje Cię dodatkowa warstwa abstrakcji. Być może piszesz skrypt, który nie jest częścią dużego systemu i potrzebujesz, aby był jak najszczuplejszy i jak najszybszy.
Jest więcej argumentów, ale myślę, że to całkiem dobre dla podstaw.
