Python, beginner's question! Repository or Object persisting itself?

I am a seasoned .Net developer who's trying to write some Python code. On one of the projec开发者_如何学编程ts I am contributing to, we have a services layer which is a set of classes which abstract away functionality and a django web app which consumes these in process services (which are just classes).

I had created a repository layer and ensured that all interaction with the database happens through the services layer through this repository. We have a document oriented database and thus we do not have the usual object-relational muck. During a recent code review, one developer who is supposedly seasoned with python shunned at this and commented that this was not the python way of doing things. He remarked that python developers are used to having a save and delete method on the object instance itself (and do not use the repository pattern as much) and this would confuse python devs looking to contribute to our OSS project. Python devs, your views? Would you be confused?

Edit: This is not django code, but will be code called by the django app (It an in process service layer)

---

Maybe that is a Django pattern, but not a Python one by all means. That said, if the target audience of your module are Django developers, I would advise you to follow as much as possible the Django philosophy and its associated patterns.

---

Django's ORM provides save() and delete() methods on the object. SQLAlchemy on the other hand has a so called session to which you add or delete objects.

Both are very popular so I'd say that both methods are about equal in terms of popularity. However in the context of a Django application going with the Django convention is probably preferable unless you have a good reason not to.

---

Best of my recollection Django's models include save() and delete() methods so you can deal exclusively with objects, rather than interacting with a database connection object. I don't know that it's instantly a Python way of doing things, but I'm pretty sure it's a pervasive Django pattern.

If I was told "this is Django code" but the code diverged from how Django does things, that might be confusing.

---

Don't Repeat Yourself. If all the data stored in the database is meant to be accessible through django (e.g., they are defined in the django models.py); there's a django-ORM that is already designed to safely (no SQL injection) and easily access the database for you via save() and delete(). There's also helpful wrapper functions to create transactions (e.g., @transaction.commit_on_success to group together actions. You can use the ORM in python scripts outside of the running django web-app. E.g., create a django management command or run a script from the django shell (./manage shell)

I definitely agree having another repository layer creates confusion and potentially leads to major issues for people using your . E.g., sometimes you have model validation that goes beyond the database validation and if you save it outside of django that validation never runs. Or maybe every time a specific model is saved, extra behavior should occur (like creating a complimentary object; or generate a task) that would be skipped if save() is not called so the pre_save post_save signals are never generated.

Granted you said this is a document-oriented-database (e.g., mongdb/couchdb), and AFAIK django does not support these sorts of NoSQL dbs, so then ignore what I said.