views:

251

answers:

5

I have an application, built using MVC, that produces a view which delivers summary information across a number of models. Further to that, some calculations are performed across the different sets of data.

There's no clear single model (that maps to a table at least) that seems to make sense as the starting point for this, so the various summaries are pulled from the contributing models in the controller, passed into the view and the calculations are performed there.

But that seems, well, dirty. But controllers are supposed to be lightweight, aren't they? And business logic shouldn't be in views, as I have it as present.

So where should this information be assembled? A new model, that doesn't map to a table? A library function/module? Or something else?

(Although I see this as mostly of an architectural/pattern question, I'm working in Rails, FWIW.)

Edit: Good answers all round, and a lot of consensus, which is reassuring. I "accepted" the answer I did to keep the link to Railscasts at the top. I'm behind in my Railscast viewing - something I shall make strenuous attempts to rectify!

A: 

Controllers don't have to be that lightweight.

However if you have some calculations that only rely on the model/s then you probably just need some sort of model wrapper for the models to perform the calculation. You can then place that into the API for the view so the view gets the end result.

Quibblesome
+1  A: 

Why not create a model that doesn't inherit ActiveRecord::Base and execute the logic there (think the Cart class in Agile...With Rails).

Brian Warshaw
+1  A: 

As Brian said, you can create another model that marshals out the work that needs doing. There is a great Railscast on how to do this type of thing.

HTH

Tim Sullivan
A: 

You don't want the logic to be in the view. However you are free to create a database view. Except, rather than create it on the database side, create it as a new model. This will enable you to perform your calculations and your actual logic there, in one place. The pain of trying to keep your views in sync vs. the one time "pain" of creating the new model ... I vote for a new model.

salt.racer
+1  A: 

Controllers don't have to map to specific models or views. Your model doesn't have to map one-to-one to a database table. That's sort of the idea of the framework. Seperation of concerns that can all be tested in isolation.

Jim