I am creating a rails app with following constraints

  • It has no database
  • It uses a web API to store and retrieve the data
  • The connection to the web API is via a custom gem.
  • The Gem has a basic functionality to make a web API call based on the parameters given.
  • I have 2-3 different kinds of object that I can think of ( or may be more precisely virtual model )

How should the structure of my program be ?

  • Should I incorporate all the method calls within the gem ?
  • Should I create models and put the api related calls in there (then through the gem's basic method)
  • Should I just ignore the model and put everything in the controller . ?

The second method seems most appropriate , but then all the methods from model would be static and I would be calling all methods in essence without any objects.

3 Answers 3


My gut tells me that you're correct to want to put some code into the Model. The fact of the matter is that while those are the functional/nonfunctional requirements on your application today - that could change. You could be required to implement a database on the next iteration of this project, or even worse the entire way you're storing data could get overhauled.

The fact of the matter is stuff changes. The better you modularize and abstract your code, the quicker you'll be able to adapt to change down the road. You'll also set yourself up for easier unit and integration testing, too. That's an important factor, because detecting problems before they become problems saves time and reputation.


I'm not familiar with Rails, but theoretically, in order to retain it strictly MVC, you should encapsulate the gem in your model (your second method).

If your Gem already defines all the data structures needed, you could decide to call the Gem your 'model' even though it might reside in an unconventional location (again, I'm not familiar with Rails so maybe you can put a gem wherever you want?). You'll surely need to pass data to the Gem's methods and get data back, which implicitly makes those parameters and return value's your model.

There's nothing wrong with having a static model. In fact functional enthusiasts would love it that way.


If you don't have too many models and sure that would be the case going forward, then create a virtual model, or if it's other way around and if API support JSON, then use JSON library.It doesn't make sense to transform data if we are not going to do any post processing on object.

  • I am going to do post processing.. obviously.. Nov 5, 2011 at 9:04
  • Creating a type model would be the recommended choice.
    – Phani
    Nov 6, 2011 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.