It's a trade-off. Loose coupling allows you to modify the structure of your program easier, but doing so in this case is going to lead to a performance hit.
That said, this isn't crazy coupling we're suggesting. It's not like we need to know anything about the user model to do this or that anything in the user model depends on this. I mean, you need to think about the specific application, but if you're writing a blog application, are you really going to want to restructure your program so that entries aren't owned by users? Are entries owned by groups a realistic possibility? Should companies be treated differently from users? I'd say no to both, but my blog application may differ from yours. On Sep 24, 9:37 am, ringemup <ringe...@gmail.com> wrote: > So the tighter coupling implied by each entry knowing about the user > profile shouldn't be a subject of concern? > > On Sep 23, 11:05 pm, Brian McKeever <kee...@gmail.com> wrote: > > > I remember a quote from either headfirst java or design patterns that > > said something like: > > "The key to inheritance is to abstract functionality." > > > I realize we're not talking about inheritance, but I think it still > > applies. > > > It may make logical sense that a user object has a blog that has > > entries, but unless a blog object adds functionality, you should just > > say that a user has entries. > > > On Sep 21, 8:33 pm, ringemup <ringe...@gmail.com> wrote: > > > > There's a pattern I keep running into, and I've been wondering if > > > anyone who's encountered it before has an opinion on how best to deal > > > with it: > > > > Imagine you have an app that could theoretically stand on its own -- > > > for now let's say a schedule, but it could be anything (an image > > > gallery, a blog, etc). This app has multiple items per "app > > > instance" (i.e. every schedule has multiple events; every blog has > > > multiple entries, etc). > > > > For your main project, tou want every user to have one instance of > > > what the app provides. > > > > It seems more pluggable to have an intermediary parent model (Schedule > > > or Blog or Gallery) between the app items (events, entries, etc) and > > > the user / user profile than to assign the items directly to the > > > user. I.e. each Event has a "schedule" FK and the user profile has a > > > "schedule" one-to-one field, rather than giving each event a "user" > > > FK. > > > > On the other hand, the intermediary model is rather pointless if it > > > doesn't have any fields of its own. It also results in more demanding > > > queries and interferes with the use of select_related. > > > > How do you typically handle this case? > > > > Thanks! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
