26

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
  • 421
  • 1
  • 4
  • 10
  • 2
    I think people would be able to provide better answers if you listed some of the libraries and frameworks that you are using to support your MVC application. While the MVC pattern is technology agnostic, not all frameworks follow it explicitly. Furthermore, most mature frameworks already have outstanding documentation and knowing which one you are using would make it easier to direct you to a pre-existing explanation that follows your line of thinking. – CLW Aug 10 '15 at 14:25
  • 2
    Database? Datasource? Its just data. –  Aug 10 '15 at 15:05
  • 2
    There are so many opinions of what "MVC" is supposed to be, that this question is too abstract to answer. – RemcoGerlich Aug 11 '15 at 09:03
  • 2
    Also, consider calling the API from your frontend Javascript code, and not having it touch your backend "MVC" stuff at all. – RemcoGerlich Aug 11 '15 at 09:07
  • @Remcogerlich that's why I proposed an addition of the actual implementation he is looking at. He could be dealing with a backend and a frontend implementation of mvc. We could have another pattern in place as well that better explains these differences. – CLW Aug 11 '15 at 17:05

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,282
  • 28
  • 31
  • 8
    The model should not have any logic and thus not be interacting directly with anything. The MVC pattern clearly calls for all logic to be placed into controllers. These controllers should be contacting the DB, API, etc... as and updating the model as necessary. This keeps your model technology agnostic, and ensures it serves as nothing more than a storage mechanism that can be passed to various views for presentation and controllers for additional manipulation. – CLW Aug 10 '15 at 14:37
  • This answer is correct, the model is not a "DB wrapper", it is a data wrapper, its job is to source the data from somewhere be that a DB call or an API call. Consider that DB calls are technically API calls anyway - you're calling SQLClient (or similar) methods on an interface that just happens to be connected to a DB. – gbjbaanb Aug 10 '15 at 14:44
  • 3
    @CLW: Model != data model. More details can be found somewhere else, e.g. http://stackoverflow.com/a/14045514/124983 – Residuum Aug 10 '15 at 14:47
  • @Residuum Your answer makes a lot more sense now that I understand you are referring to the Model as more of a Service Provider rather than the traditional POCO as described elsewhere. While, I don't disagree with the quality of the overall approach you are advocating, it is unfortunate that there isn't a different, more descriptive name that could be used instead. – CLW Aug 10 '15 at 15:31
  • @CLW: In MV* patterns, data is never the model, but part of the things that are sent between the different layers. See e.g. http://programmers.stackexchange.com/a/280392/20580 – Residuum Aug 10 '15 at 15:43
  • network data require mechanisms such as callbacks, possibly canceling, progress, ... which need to be known by the controller in order to give information to the user through the view. MVC is way too limited to address networking by itself. – njzk2 Aug 10 '15 at 21:53
  • 2
    @CLW: _business logic_ shouldn't be in M, V, _or_ C. Models are an abstraction of a data store, views and controllers are your user interface. They are the periphery of the actual application you are building, which should be "just code", that doesn't have to know about things like databases and the web. – RemcoGerlich Aug 11 '15 at 09:11
  • 3
    The "model" part is interpreted many hundred different ways. I was always taught that a model is a representation. A model train is a representation of a real train, with little moving parts that move just like the real one. Similarly, the model in your app is a representation of the systems and processes you're building your software to replace. As such, *models have behaviour*. That behaviour incorporates your "business logic". Thus, when you ignore pure CRUD data access, UI, and interop, what's left is probably your "model" - domain classes, business rules, etc. – anaximander Aug 11 '15 at 09:50
  • 1
    @RemcoGerlich I did not say anything about business logic. I simply stated that since most interpretations of MVC call for the model being nothing more than a simple struct representing your application state, that the responsibility of contacting the DB, API, etc... should not be placed within the model because it should be logic free. The duty of communicating with the database should either fall on the controller or another object managed by the controller. – CLW Aug 11 '15 at 12:05
  • @CLW the wording "The MVC pattern clearly calls for all logic to be placed into controllers" is a bit misleading, especially for those new to MVC. A controller's sole responsibility is handling and delegating UI requests to the Model, hence the common saying "Skinny Controller." If you have a Fat Controller then you are not adhering to the ideas behind MVC. – FailedUnitTest Sep 20 '16 at 14:13
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,888
  • 1
  • 26
  • 35
  • 1
    Agreed: The model(s) were always supposed to be the entire problem domain. In complicated apps it was always supposed to be the bulk of the code. They consisted of all the code that would not change if you change the User Interface (say, from web site to GUI or even command line application). Think of a compiler. Only a very small portion of the code would change if you went from a command line UI to a GUI, or even web UI. All of the guts of such an application are the models. – Kevin Cathcart Aug 10 '15 at 18:08
  • 1
    In the original Smalltalk use of the term, _every UI control in the interface_ had its own model, view and controller. – RemcoGerlich Aug 11 '15 at 09:06
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
  • 274
  • 3
  • 5
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,546
  • 1
  • 11
  • 21
  • I can't find what you quoted. Instead, I read: "Model. The central component of the pattern. It is the application's dynamic data structure, independent of the user interface.[5] It directly manages the data, logic and rules of the application." – Mateus Felipe Apr 23 '20 at 13:06
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
  • 3
  • 5
    I think when you say "model" here, you're referring to "viewmodel", which IMO is a separate thing. A viewmodel gets data from the controller to the view, and as such is either an implementation detail of the View, or an aspect of the communications between View and Controller that doesn't really fit into either (depends how you see it). The "Model" in MVC refers to a system model - a representation of the system that incorporates its data, structure and behaviour. The Model is state and logic; the Controller is what causes the logic to run and the state to change when the View is manipulated. – anaximander Aug 11 '15 at 09:54
  • @anaximander No I'm referring to the Model in a fairly strict interpretation of of MVC (see Wikipedia, Microsoft MVC, Head First Design patterns, etc...) In those instances the Model is nothing more than a simple struct for passing data around and there is no such thing as a viewmodel. While the Microsoft MVC implementation does add various attributes to the model, this is more for convenience than anything. In the end the purpose of the MVC pattern was to facilitate good practice of code separation and limit side effects. – CLW Aug 11 '15 at 11:56
  • @CLW Wikipedia clearly states that Model "directly manages the data, logic and rules of the application", and Controller "accepts input and converts it to commands for the model or view". Thus, the logic and business rules SHOULD be in Model. The Controller is only a interface between View and Model. – Mateus Felipe Apr 23 '20 at 12:59
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