I am an MVC newbie. As far as I can tell:
Where does the Business Logic go?
Take a large enterprise application with:
What is an appropriate way for an MVC web application to sit on top of this (in terms of code and project structure)?
The example I have seen where everything just goes in the Model folder don't seem like they are appropriate for very large applications.
Thanks for any advice!
A1: Business Logic goes to Model part in MVC . Role of Model is to contain data and business logic. Controller on the other hand is responsible to receive user input and decide what to do. A2: A Business Rule is part of Business Logic .
Business logic should live in the data model. And, what's more, it should live in the graph data model because that's the right abstraction for the next twenty years. If you've been paying attention to this blog or to Stardog generally, then you must have known this is where we were going to end up.
So what is Business Logic? The business logic are the set of codes in your application that handles communication between an end user interface and a database. In ASP.NET MVC your business logic will contain your domain models (entities), database context class, Repositories, services etc.
In my apps, I usually create a "Core" project separate from the web project.
Core project contains:
Web project contains:
The key point here is that the web-based Models folder/namespace is ONLY used for presentation-specific models that document the specific variables needed for a given view. As much "business logic" as possible goes into the core project.
Model View Controller sounds like it addresses your 3 tiers, but that's not the case. It really organizes how your UI is put together. The Controller is at the middle, and typically (A) does stuff using Business objects and (B) from Business objects gets the Model objects to pass to the View. The MVC part of your system (the UI functionality) has no idea what's happening on the other side of the business layer. DB? Service calls? Disk IO? Firing lasers? So, MVC-B-? would be an acronym that describes MVC and how it hooks up.
Think of the Controller at the center, with a line going down to the Business objects. The controller will typically get the Model from the Business objects to pass off to the View, but the Model is just data. That's key. The Controller is now the smartest part of the system in a sense, but the Business objects are still the most powerful.
So, the Model objects are a large part of the communication between the Controller and the Business objects. Further, every view has a VM (View Model) object that it takes, that might be a Model, but might be something constructed by the Controller to pass more complicated sets of information to the View.
So, a controller (1) takes data from the client and does stuff with the business objects (if necessary), communicating using model object perhaps, and then (2) get's Model object(s) from a Business object(s), constructs a VM, and gives it to a view (possible several) to render.
At first it really will seems like layers and tiers all over the place, especially since getting into MVC is a good time to increase your use of interfaces (see last 3 or 4 Solid principals) and unit testing. You'll have probably many more files in your project than you otherwise would. Very quickly though you see that is in fact a great way of organizing things.
As this "top" part of the system, the MVC part, we just do not care how the Model objects were constructed or what the Business objects do with them. Don't be surprised of course if your Customer model object happens to look a lot like your Customers db table! This is normal and common. However, your customer Model object and your customer Business object will really have separate lives. It's a good time to consider the Repository Pattern.
Fight temptation to be lazy and put lots of logic into the Controller. Strive at every moment to put concerns in the place where they below. The Controller is just for wiring things up. If a lot of code there is necessary in order to construct an adequate VM for the view to use, this is okay, because this is the controllers job. Too often you see business logic or rendering logic in the controller. Put it where it belongs!
I tried to balance comprehensiveness with brevity, but you asked a huge question!
MVC is not a complete architecture for your needs, it covers only the presentation layer. Your controllers should talk to a business layer an get back Model objects. The business layer can talk to other layers, like database-access, web services, file system, etc.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With