Reputation: 1440
I am pretty new to Rails, and my biggest concerns yet is where to put my logic to maintain an object oriented design and at the same time adhere to the MVC pattern. So I guess this just as much a question about MVC as it is about Rails. This is my scenario:
I have an import function in my Rails app that parses an uploaded Excel-file of orders and imports its content. When I wrote the function I put it in the OrdersController. I knew from the start it wasn't the best place to put it, but I'm not exactly sure I want to put it in the model either. If I was to put it in the model, it would be as a class method, e.g. Order::import_from_excel, and maybe that would be fine right now. But if the task would grow and become more complicated, it would probably need to be split into several methods and the model would be cluttered. I would in that case see it fit to move the whole import functionality into its own class, e.g. OrderImporter which would be perfectly normal in a none MVC, object oriented environment. But where would I put such a class, in lib?
Upvotes: 0
Views: 93
Reputation: 4670
The logical place to put it would be in the model, so I think having something like Order::import_from_excel
would be a good idea. Disclaimer: I'm an advocate of the fat model, slim controller philosophy, so other people might hold different opinions about this.
However, you should encapsulate the functionality into a seperate class in lib/
that gets instantiated and called from import_from_excel
. This helps testability, decreases coupling and will probably help you if the requirement to import other things from Excel arises in the future.
Upvotes: 1