Do I use a model or controller in an existing MVC application for implementing an integration that makes API calls?

Question

I have an existing application using Codeigniter Framework (MVC). I need to implement an integration in the software with the external cash register (e.g., making REST API calls). I need to either make a controller or a model (or both), but I don't fully understand which.

The functions within the class will be doing the various business logic of making calls to other model functions to retrieve appropriate data, format the JSON, send it and process the response from the API. This makes me think that I should be making a controller because it does no database calls itself. The thing that is making me doubt is that there is no need for an associated view and that while it's not doing IO operations with the database, it is doing IO operations with the API.

Should I make this a controller and only additionally create a model if there are database IO functions specific to this integration? Or should I also have a model and put specific API IO functions in it (e.g., sendData(), etc)?

Answer 1

Where you, and many others with you, including tutorial authors, go wrong is that you equate the MVC Model with a database. This could not be further from the truth.

Within the MVC pattern, which is a User Interface pattern, the responsibilities are

• View == Show things to the user
• Controller == Receive input from the user and (especially in web context) tie things together
• Model == Everything else.

To reiterate, the MVC Model is responsible for everything that is not related with the user interface. That includes persistently storing data in a database, but also communicating with third-party services, all of the business logic and whatever else you can think of.

For that reason, when you write an application of a decent size, it is good to apply other architectural patterns (to the Model part) as well to keep things manageable.

Answer 2

Remember that MVC is a user interface design pattern, not a holistic software architecture. Not everything is an M, a V, or a C. Plenty of things fall into a gray area between models and controllers. Infrastructure code, like making database or web API calls, fits into this gray area.

Unfortunately there is no prescribed place for this logic in MVC, so place it where it makes the most sense. The basics of object-oriented programming become your guiding light.

Making web API calls is its own concern in the application. This justifies placing this logic in its own class. The controller in MVC is a coordinator of sorts. Controllers need access to data in order to initialize the model in your typical web MVC application, so the controller would need a reference to this new object that makes web API calls.

I haven't used Codeigniter in... 15 years? I'm not sure if it uses a dependency injection framework. If it does, configure the DI container to recognize this new class, and pass it as a parameter in your controller's constructor. If you don't have a DI container available then you are stuck initializing this object in the controller.

There are no patterns for naming this new class either. Lots of applications calls this a SomethingService, or SomethingRepository or SomethingStorage. Use your best judgement on the name, but put the logic to call the web API into its own class. It doesn't fit in the M, V, or C and it's doesn't need to.