“Where do you put business logic in MVC architecture?”
When I stepped back, after outside conversations on this subject, the question itself became interesting. The debate is about where to locate functionality in an artificial, and much too large-grained classification system. And there’s no consensus opinion! Functionality inherently “belongs” to some module in a software system. Cohesion and coupling are the guides.
What I want, as I work with a system, is a set of classes that represent the business entities, products and processes (some processes are common to multiple applications). Whenever I need functionality that doesn’t exist, I figure out how to make it work, then I figure out where each piece of that new code should go in relation to those classes. That often means tearing down, a little bit, something in the existing implementation and reworking it with new understanding of the domain. Every time I do that, I add value that will multiply. The challenge sometimes, is convincing everyone that it is well worth the effort to find ways to generalize the functionality into parameterized method calls. It’s not always easy to trust polymorphism at first. But it pays off when we make each function as loosely dependent as possible on the system’s architecture.
Unlike the mechanical world, we make virtual things. So we can make building blocks that work in a virtual toaster and virtual space shuttle. Call it M, V or C, I get a kick out of accomplishing a lot with a few lines — and I don’t see that level of reusability achieved when engineering is so heavily influenced by these terms; functionality gets walled off. MVC, by the way, is a 32 year-old concept. Is it really something on which to base modern application architecture?
What I want to ask of those who say that “business logic” belongs in controllers…
Granted, I am for the first time using a framework that actually spits out classes named model and controller. But what I see is controllers being created for different “sections” of the application. And I see granular operations in the controllers that express a lot of business domain knowledge. Some of it’s duplicated between controllers in the application; how could it be shared for new apps? Does anyone take the position that controller classes should be portable between applications? Seems wrong to me, since there will be a lot of code strictly related to the current application. How is this resolved?
As I said before, as we move closer to the data store and farther from the application, the code should become more general, and that means reusable. So it belongs in something that represents something longer-lived than this application. And building multiple applications on the same schema is way common.
In other words, code belongs in exactly the place that allows you to never have to write it again. That means, to me, looking at the current system. What is it related to? Whose knowledge does it represent? Is it new or part of something bigger? How should it be dissected so that as much as possible is sensibly reusable?
Copy and paste is like talking on your cell phone and driving. No one admits they do it, but it’s everywhere. If your team is duplicating code, ask yourselves why.