Creating Reusable Django Apps?

Question

I am somewhat of a Django beginner and have been trying to decouple my applications as much as possible and build it in as small re-usable pieces as possible. Trying to follow James Bennett's strategy of building re-usable apps. With that in mind, I came across this problem.

Let's say I had an app that stores information about movies:

The code would look something like this:

class Movie(models.Model):
    name = models.CharField(max_length=255)
    ...

Now, if I wanted to add ratings, I could use django-rating and simply add a field to my model:

class Movie(models.Model):
    name = models.CharField(max_length=255)
    rating = RatingField(range=5)
    ...

This inherently mean that my Movie app is now dependent on django-ratings and if I wanted to re-use it, but no longer needed ratings, I would still have to install django-ratings or modify and fork off my app.

Now, I could get around this by use try/except with import and define the field if successful, but now my movie app is explicitly tied to the rating in the database table definition.

It seems much more sensible to separate the two models and define the relationship in the ratings model instead of the Movie. That way the dependency is defined when I use the rating, but not needed when using the Movie app.

How do you deal with this problem? Is there a better approach to separate the models?

I also wonder if there are any major performance penalties in doing this.

edit: I want to clarify that this is more of an example of the problem and a somewhat contrived one at that to illustrate a point. I want to be able to add additional information without modifying the "Movie" model every time I need to add related data. I appreciate the responses so far.

Irredeemable

Answer 1

In this case, personally, I'd keep it simple and just leave rating on the model. You have to balance re-usability with simplicity of implementation. It's great to make things reusable, but is your Movie model really useful enough to warrant the extra work? And is it that bad to have a dependency? I think much of these design decisions are subjective. There was a good talk this year at PyCon on this subject: http://blip.tv/file/4882961

Urbanism

Answer 2

First, I agree with zeekay above, you should introspect whether that amount of re-usability is worth it, for your model.

If it indeed is, you can create a new movierating app that has a RatingModel that has FK to movies.models.Movie and the rating field.

You will never-the-less pass the rating somehow to the the templates. For that, you can create class-based-views and in the movierating.views you can extend and override the get_context method.

Don't forget achieving reusability is a fundamental value judgement that a developer has to make and over-doing it could be as bad as the not doing it in the first place.

Multifoil

Answer 3

Having dependencies is not necessarily a bad thing. For something like a field (rating, timedelta, JSON object), where there is no builtin field that does what you need, having to include a seperate app that handles that (and perhaps some related functionality, like template tags) is a feature, not a bug.

More of an issue is when your apps' models reference models from other apps. Of course, this happens in the real world, but in that case, it makes it much harder to identify isolated models.

Ustkamenogorsk