27

I'm building a web application using a MVC pattern. Following this kind of architecture we can see that all the methods used to interact with database are implemented in the model.

But what happen if I have to call a service exposed by others on web? For example, I would like to access the Facebook API in order to get all the follower of my page, so, where I put these methods?

Obviously the view is not a good idea because this module is dedicated to the presentation, the controller should not be used to retrieve data but the model is usually dedicated only to the interaction with database.

So, can you give me some hint about that? And please, can you tell me if I'm making some mistakes about the MVC architecture?

Ema.jar
  • 431

6 Answers6

39

The model is not limited to interaction with the database, the model is responsible for getting and manipulating data.

So, to your view and controller, it should make no difference, if the data comes from a database or from a webservice or is even totally random, therefore you should do it in model.

MVC is a presentation pattern, that only separates the different representation layers.

It does not mean, that model has to be a uniform mess of spaghetti code. Your model itself can be layered as well, but the controller should not know, where the data comes from.

A public method in your model can be structured like this (Pseudo-code), which can be called by your controller:

public MyDataClass getData(int id) {
    WebServiceData wsData = WebService->getData(id);
    DatabaseData dbData = ORM->getData(id);
    return new MyDataClass(wsData, dbData);
}

WebService and ORM may need to be instances of interfaces that can be replaced by mocks via dependency injection, but your controllers and views do not have to change for testing purposes.

Residuum
  • 3,332
  • 31
  • 31
12

There's a common (intentional?) misunderstanding about what M, V and C are. Not about the roles they take, but what are they.

In the original, desktop GUI definition of MVC, they were modules. Typically an application had several of them, sometimes working in triplets, sometimes having a variety of views and models that a few controllers could mix and match.

In web frameworks, OTOH, they tend to be seen as layers, where they's only one of each and deals mostly on covering some subyacent abstraction level: "the model layer abstracts the database", "the view layer implements presentation", "the controller layer processes user input".

So, I'd say that you already have a model, dedicated to interaction with the database, and now just have to create another model, to deal with your source API. If you make them as similar as possible, then most of the controller and view code can work seamlessly with either model.

Javier
  • 9,958
5

Part of the difficulty with any discussion of MVC is that different groups have co-opted it to mean different things. The implementation of MVC used in, say, a Rails app, would be almost unrecognisable to someone writing a Swing app. To the extent that MVC is still a well-defined thing, it's more of a set of guiding principles (separate the core application from its visual representation, provide flexible mechanisms to allow the two to be plumbed together), that can be implemented in various ways.

Indeed, there's a tendency towards giving different MVC-derived designs different names (see this article by Martin Fowler for some discussion of this), or even to give up on precise naming - for example, AngularJS describes itself as a Model-View-Whatever framework.

So, it's hard to answer without knowing which version of "MVC" you're working with. However, an API request would typically be part of the core application (the part that shouldn't change if you decide to use a different visual representation), which in many implementations would be contained entirely within the model.

James_pic
  • 341
2

Here, the model is described like this:

A model stores data that is retrieved to the controller and displayed in the view. Whenever there is a change to the data it is updated by the controller.

I'd say that the controller either includes the logic of calling the service or calls a separate Service object. If the service is separate, you can more easily create tests, say, if no connection to a service over a network is possible, some TestService could provide responses from the Service locally.

Also check out this answer that suggests that the Controller calls the service.

Community
  • 1
null
  • 3,680
2

Your model should never contain any actual code, and should be seen as more of a message or a struct used to manage content manipulated by the controller and displayed by the view.

Your controller should be responsible for contacting any APIs, databases, services, etc... requesting a change and managing any necessary updates to the model.

The entire strength of the MVC pattern is that it decouples logic (the controller) from the view and state (the model). In doing so you are now guaranteed that only code in the controller can create side effects as the view and model are simply not allowed to make changes.

It also allows for better reuse of code as a model can be shared between various controllers and views.

CLW
  • 137
1

Might be way off here, but this is how I feel about WebApps and working with [complex] remote API's in many cases:

I would make it a class (ie, a library of data mitigate methods) instead of model (ie, stack of data mitigate functions). It seems like it would act more transparent, more logic/schema agnostic, and you could use it wherever without loading->calling a model/controller itself each time you want to use it. The logic is still separated, the datapoint is still flexible, and it seems more open for interoperability in strange cases like stacking clientAJAX->appJSON->appLIB->remoteAPI->remoteJSON etc to poll the endpoint indirectly.

dhaupin
  • 111
  • 5