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.