It is easy to find many descriptions of what MVC is - for instance here, here or in this video.

I'm curious, what is NOT MVC?

or more precisely - In a MVC-using app, what is everything else apart form MVC?

.

I see the tendency to start explaining MVC in a form of

Separate the application into three parts[...]

Which seems to suggest that you should try to fit in as much as you can (or all) of your design under either Model, View or Controller.

.

Yet, it's easy to see that in most explenations MVC is primarily described as a user interface design. How in this situation do I treat non-UI elements?

  • Do I bend definitions of non-UI elements and try to figure out whether they could fit to either Model or Controller?
  • Is there a separete description in MVC design that deals with non-UI elements?
  • Is there a description of how MVC interacts with such elements? Is it all through Model? All through Controller?

.

For example:

I'm wondering how do I treat the part of my application which is used only for monitoring my local network and storing the information in a database. It has no UI related functionality and its sole puprose is to fill in the database with file related information, which then in turn is presented to the user through the web interface.

  • In Rails beyond the common MVC folders you have things like Mailers (act like a spercial kind of controller + view), libraries, helpers, scripts etc. For example I have several scripts that import/export data from SOAP or REST interfaces. There are the classes that do the import (kind of models) and the classes which control when and what to import (run by cron jobs) which are kind of controllers. But since they don't fit in the Rails MVC structure (which only handles the browser part) I just put them in libraries. But from a technical view they are controllers and models (business logic) – thorsten müller Nov 5 '15 at 11:24
up vote 7 down vote accepted

I'm wondering how do I treat the part of my application which is used only for monitoring my local network and storing the information in a database.

Several architectures implement such code differently, but in a layered architecture, you would need to create layers, e.g. DataAccess layer, Business logic layer. etc..

Your Model (there are different types of models) will interact with these layers as required, it all depends on your application or software architecture really.

Do I bend definitions of non-UI elements and try to figure out whether they could fit to either Model or Controller ?

I would say your "non-UI elements" is actually your business logic that needs to go in Model which then can interact with different layers e.g. DB layer etc..

Should I add logic to my Controller

enter image description here

Further Recommendations

Here are couple of sample projects developed based on DDD using MVC and other technologies that may help you understand this subject further,

EFMVC - ASP.NET MVC 4, Entity Framework 5 Code First and Windows Azure

Sample web app for ASP.NET MVC 5, EF 6 Code First, AutoMapper, Autofac and TDD

  • That's a very good clue, thanks! After reading a lot more about it I'm still a little confused as to how models should be split. The View, Domain, Data models seem to encapsulate the same information, unless the app grows to be moderately large. Would it be valid to have only one model for smaller size web apps? Is there any particularly good explanation you could recommend? – Voy Nov 6 '15 at 12:37
  • 1
    I added links to few projects that will def going to help you, new developers often get confused when they see duplicate code in OOP but most times its there for a good reason, smaller size web apps will grow - you never know.. so I would recommend follow a famous architecture which meets your goals most and slightly change it IF you are confident to do so, other then that it's a never ending debate when it comes to application design. – Muhammad Raja Nov 6 '15 at 14:12

An MVC application is one where there is a conscious architectural decision to separate out components of the presentation (usually through the User Interface) that deal with three specific concerns:

  • The Model, which represents the information which is to be displayed, but which is completely agnostic of how the information is presented.
  • The View, which displays the information in the model, but which has no idea about how the model has been built.
  • The Controller, which identifies the right Model and View for the occasion, and brings the two together

In theory, and often in practice, the same model can be connected to multiple views – the appropriate view depending on the scenario (e.g. Mobile browsers vs Desktop, or html vs json). And the same view can be used to display many different models, provided the models have enough in common with each other for that to be useful.

In NOT MVC applications, these three systems are not kept separate from each other (common in older applications) or are divided up in different ways.

The MVC application can have many other components in it too. These components may be used in constructing the models, updating the data layer, enforcing security, logging, whatever else your application needs.

  • 1
    that is a great answer but I didn't quite write the question right. I meant 'NOT MVC' as in 'everything else apart from MVC', I'm guessing you're referring to an application that doesn't include MVC design at all? – Voy Nov 6 '15 at 12:28
  • @Voy I don't think that changes my answer. In order to be an MVC application, I believe the division of these three components needs to be intentional. Even if someone were to accidentally hit on the pattern, but not commit to maintaining it through the life of the application, I don't think you would be looking at an MVC app. – Bill Michell Nov 8 '15 at 23:47
  • - Thanks, that's a good clarification. What I meant in my comment is that elaborating on the last paragraph of your answer was what my question was about - what are these 'other components'? A paragraph before that you describe a NOT MVC app as one that doesn't include MVC at all. The rest of the answer describes the MVC. Altogether it gives me a good overview of the topic and I appreciate your effort but not quite exactly the information that I've been looking for - hence I guessed I didn't write my question clear enough. – Voy Nov 9 '15 at 15:14

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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