This is a complicated question with many possible answers, so I’ll break down my situation into simple bullet points to help narrow down the solution:
My Rails App Has the Following ‘Objects’
- Author
- Feed
- Update
- FeedTypes
The Objects are Related Like So:
- Authors can have 1 or more Feeds
- Feeds can have one or more Updates
- A Feed has one feedType
Example Setup:
- Author: Levi Hackwith
- Feed: view-source:http://www.twitter.com/statuses/user_timeline/opnsrce.xml
- FeedType: Twitter
- Update: The tweets inside the Feed
My problem and My Questions:
Problem:
I need to parse the above-mentioned feed and store each tweet in the updates table. To parse the feed, I was thinking of writing a custom Feed class which would get inherited by TwitterFeed, FacebookFeed, TumblrFeed, etc.
However, I’m not sure if this is the ‘Best Practice’ for solving this kind of problem.
Questions:
- When is it appropriate to develop a custom class to perform an action in RoR (as opposed to going through the Model or Controller)?
- If this situation does not call for a custom class, which element should I apply the parsing logic to? The model or the controller?
- If this is an appropriate situation for a custom class, where in my rails application should I store it (in other words, what’s the right ‘convention’)?
You are probably going to have a background task invoked from time-to-time to check all the feeds, fetch new updates and store those in database. This task is completely separate from controllers and it should be possible to invoke it without any controller logic.
Your abstraction looks fine. You can further have something like
XmlFeed < Feedif several feeds share a common XML structure.1) Controllers should talk to database/models and pass relevant data to the view to render. Everything else should be either in a model, helper or library.
2) Are you asking where the parsing logic belongs to? In MVC, I think this would belong under the Model and/or a helper class, but definitely not the controller.. it’s not its responsibility.
3) Classes holding data go into app/models. Classes that have nothing to do with holding data, go into the lib directory.