Where do computed values belong in the MVC pattern?

Question

In the application I'm building, I have a concept of a User.

In the app, users have profile pages.

These are pretty simple. They are basically just like /profile?id=3 or whatever, where 3 is the user id of the user whose profile I want to see.

Does it make sense to add a url_for_profile method to the User model, or should I make a view for user profile URLs or do something else entirely?

There are a bunch of different approaches that would all work, but I'm curious as to what is considered best practice here.

Thanks for the advice!

Answer 1

It depends on what layer is deciding what the urls are.

If the urls are defined by a model layer for some reason (client-server app that needs to reference the website occasionally), then the model objects should have methods for retrieving the profile url.

If the urls are purely a concept of the presentation layer (website where model is just serving up the user data itself), then it's a decision to be made by the controller layer. If this is the case, it might make sense to create a UrlFactory or something of the sorts where you can feed it a user id and it will generate the corresponding profile url.

Answer 2

url_for_profile is also recommended because tomorrow if you want to cache the profile and when the number of users grow enormously high then you might need to cluster your application and that time this method can be useful.

Although you may create a different view, but addressing urls implicitly can create problems on longer run, as project and database grows, it becomes too difficult to understand and manage what is going where. So even if you are creating a new view, you still should have url_for_profile, which can be used for clustering. If you notice, every link of microsoft has this format... go.microsoft.com/linkID=XXXXXXX ,

Answer 3

I can't see anything in your requirement that says a User needs to know what a URL is. If you implement this method, you are implying you may end up with things like Order.url_for_order or Cart.url_for_cart. If you then wanted to change the way URLs were specified, you'd have to change all the classes. It would be preferable to have all objects in your system have an ID and a View helper class which has a method such as: URLHelper.url_for_object(myobject)

What you absolutely need to do is isolate objects in your model from the plumbing of how they are located and leave the locating up to the web framework you are using. A general best practise is that every class specifies an ID and a handler in your web infrastructure depends upon the class it renders. It retrieves the class by an ID passed to it.

So you see the dependency is one way. The View class depends upon the underlying model, but the model does not depend upon how it located. If you subsequently want caching of objects, you can implement this at the view layer, again the underlying object has no knowledge or dependency on whether it is being cached.