Should i define exporting in a model or a controller?

I have an Rails app that needs to export data. The data export is a complex operation that creates an external database that contains information from various models. I have the data export routines written as a separate rake task at the moment a开发者_开发技巧nd now I want to expose them to the user as well.

What I can't figure out is whether to create a model that contains all the logic for the export, so essentially the model would represent a single export instance or should I create the routines as a helper library and use that directly from a controller, which in a way makes sense too.

Basically, "exporting" is just creating another way to access data.

What manages ways to access and to represent data is the view. So you should just create another view, not a model or a controller.

The view you'll create, of course, will call some kind of exporting functionality. The exporting function takes a data model as an input and returns data in the "exported" form. This may be either a method in your model object ("export me"), or a separate function residing in a script in your lib/ folder.

However, when you implement this exporting function, you might want to use another data model (for instance, to cache the exported data). But that's an implementation detail of the exporting function, and it may not be needed at all.

In my humble opinion, it seems like you should create a module or class (whichever is more appropriate for your export implementation), and call that from the controller. To me, it seems like a user is making a request, and the controller is then directing that request to the external library to fulfill it, which can then report back to the controller its done, and the controller can inform the view.

Putting it in a model only makes sense to me if you're going to store the requests for export in the database.