The Stack Overflow podcast is back! Listen to an interview with our new CEO.

Hot answers tagged

282

Yes you should. It not only makes your back end re-usable but allows for more security and better design. If you write your backend as part of a single system, you're making a monolithic design that's never easy to extend, replace or enhance. One area where this is popular at the moment is in Microservices. Where the backend is split into many little (or ...


156

MVC is a software architecture - the structure of the system - that separates domain/application/business (whatever you prefer) logic from the rest of the user interface. It does this by separating the application into three parts: the model, the view, and the controller. The model manages fundamental behaviors and data of the application. It can respond to ...


136

Analogy I explained MVC to my Dad like this: MVC (Model, View, Controller) is a pattern for organising code in an application to improve maintainability. Imagine a photographer with his camera in a studio. A customer asks him to take a photo of a box. The box is the model, the photographer is the controller and the camera is the view. Because the box ...


121

Layers, modules, indeed architecture itself, are means of making computer programs easier to understand by humans. The numerically optimal method of solving a problem is almost always an unholy tangled mess of non-modular, self-referencing or even self-modifying code - whether it's heavily optimized assembler code in embedded systems with crippling memory ...


88

You cannot possibly avoid building an API. Even if you build "just a Website", it will still need to get its data from your backend somehow. However you decide to do this, that is your de facto API. Knowing this, the real question isn't whether to build an API, but how to build it. You can do it on-the-fly as an ad hoc thing -and indeed, many Websites are ...


86

MVC is mostly a buzzword. It used to be considered a pattern, but its original 1979 definition has been dumbed-down, passed-on, misinterpreted, taken out-of-original-context. It's been ill-redefined to the point it starts resembling a religion, and while this certainly helps its cargo cultists defending it, its name doesn't associate anymore with a solid ...


82

The business logic should be placed in the model, and we should be aiming for fat models and skinny controllers. As a start point, we should start from the controller logic. For example: on update, your controller should direct your code to the method/service that delivers your changes to the model. In the model, we may easily create helper/service ...


73

MVC works at a much higher level of abstraction than single objects, and in fact each of the three (model, view and controller) will typically consists of many objects that each have both data and behavior. That objects which encapsulate data and behavior are a good fundamental building block for programs in general doesn't mean it's the best pattern at all ...


71

OOP does not restrict interactions among objects that each have their own data and their own behavior. Think of an ant and an ant colony analogy: behavior of an individual ant (run around all day, bringing food) is different from behavior of the overall colony (find the most desirable place, make more ants). The MVC pattern describes the desired social ...


70

You don't explain MVC. What you do is explain that this is a restructuring of the codebase. A restructuring that simplifies the codebase and therefore enables the developers to make faster and better changes to bug reports and feature requests, with less bugs. They don't need to know the technical details, just why it was done, what was achieved by doing ...


69

ElYusubov's answer mostly nails it, domain logic should go into the model and application logic into the controller. Two clarifications: The term business logic is rather useless here, because it is ambiguous. Business logic is an umbrella term for all logic that business-people care about, separating it from mere technicalities like how to store stuff in ...


63

I know microservices are all the rage right now, but they aren't always worth it. Yes, loosely coupled code is the goal. But it shouldn't come at the expense of a more painful development cycle. A good middle ground would be to create a separate data project in your solution. The data project would be a .NET class library. Your ASP.NET MVC project would ...


63

MVC is conceptually elegant: user input is handled by the controller the controller updates the model the model updates the view/user interface +---+ +----| V |<----+ user | +---+ | updates input | | v | +---+ +---+ | C |--------->| M | +---+ updates +---+ However: The ...


61

The fundamental motivation is this: You want to be able to rip an entire layer out and substitute a completely different (rewritten) one, and NOBODY SHOULD (BE ABLE TO) NOTICE THE DIFFERENCE. The most obvious example is ripping the bottom layer out and substituting a different one. This is what you do when you develop the upper layer(s) against a ...


50

Heh. Martin Fowler agrees with your confusion about MVC: I don't find it terribly useful to think of MVC as a pattern because it contains quite a few different ideas. Different people reading about MVC in different places take different ideas from it and describe these as 'MVC'. If this doesn't cause enough confusion you then get the effect of ...


46

Yea, both the model in the code and database are the "Model". The model has to do with what your application "IS", and the controller is what it "does". Any code dealing with direct persistence to the database is considered the Model. Note: MVC is a pattern, so don't over-think it. It's easy to get all super into doing MVC the right way, but at the end ...


46

You should always remember - MVC is a UI-related pattern. If you are building a complex application you should take everything, that is not related to UI, out of MVC triplets to any other classes, subsystems or layers. It was my biggest mistake. I spent a long time understanding that simple rule: Do not spread a MVC pattern amongst the whole application, ...


45

Considering that MVC is from 1977, and the web was only invented in 1991, it should be pretty obvious that MVC is not only for the web.


44

MVC is an exercise in Separation of Concerns, a UI architecture. It is a way to corral the complexity that can occur in user interfaces due to the presentation not being separated from the content. In theory, all objects can have behavior that operate on the data they contain, and that data and behavior remain encapsulated. In practice, a given OOP ...


41

While I endorse the gist of Oded's answer, that you should explain technical projects to business managers in "their language," I have a qualm about "they don't need to know technical details, just why it was done." If you are in a project or investment review meeting with department heads, and you declare "this is what we're doing," they may want to ask "...


39

The best way to define it is to go to the original writings of Trygve Reenskaug, who invented it: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html This paper, in particular, is generally considered the definitional text: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf MODELS Models represent knowledge. A model could be a single ...


39

Why not just perform all the logic on the model in the view itself? The controller is the glue that binds the model and view together, and it's also the insulation that keeps them apart. The model shouldn't know anything about the view and vice versa (at least in Apple's version of MVC). The controller acts like a two-way adapter, translating user actions ...


37

I'd like to say it's cargo cult programming, but there are technical reasons for this structure. Asp.Net MVC took a convention over configuration approach to nearly everything. By default, the Razor view engine searches the Views directory in order to resolve which view to return from the controller. There are however a few hacks to get a different project ...


36

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 ...


34

For your example I would create two controllers: Sessions Controller for Login and Logout (create and destroy session for REST like layout) Files Controller for everything on files (index=search and create=upload) In general a RESTful approach where you think about everything as a resource that can be displayed, created, edited and destroyed gives you a ...


34

No you shouldn't. If you don't have immediate plans to create alternative frontends (like mobile or desktop apps or separate web application) which access the same backend, then you shouldn't introduce a web service layer. YAGNI. Loose coupling is always desirable (along with high cohesion), but it is a design principle and does not mean you have to ...


31

In my opinion, you have to distinguish between the MVC pattern and the 3-tier architecture. To sum up: 3-tier architecture: data: persisted data; service: logical part of the application; presentation: hmi, webservice... The MVC pattern takes place in the presentation tier of the above architecture (for a webapp): data: ...; service: ...; presentation: ...


30

First Answer: A key role of the model is to maintain integrity. However processing user input is a responsibility of a controller. That is, the controller must translate user data (which most of the time is just strings) into something meaningful. This requires parsing (and may depend on such things as the locale, given that for example, there are different ...


Only top voted, non community-wiki answers of a minimum length are eligible