Where is business logic situated in MVC pattern?_问答_开发者

I use Zend framework and Doctrine. In many projects, business logic is built into the controller. This approach seems wrong as me.

The best setup I ever saw it is used service layers, and this is where the business logic was written. All I had to do was create a form, validate it, 开发者_开发技巧and use some business logic in service layer. Result validation, business logic and work with one method (for example: newProduct($postData)).

What is the right way to organize my business logic in MVC? Maybe I need to read some books, or see some examples of source code.

I can't speak for the Zend framework (or for anything you're working on that was built using it), but in the MVC pattern in general the business logic belongs in the Models.

You may have heard the statement before that you should "keep your controllers light and your models heavy" (or some variation thereof). The idea is that the Models are your domain (your ubiquitous language) and all business logic should be encoded in them and in their interactions. The controllers are just event handlers in MVC to receive requests and translate those requests over to the Models.

Edit: (In response to your comment) - I'm afraid we're having something of a language barrier here. But, to add to the point and hopefully help you with regards to building the model yourself and data being primary, consider a quote by Eric Raymond: "Smart data structures and dumb code works a lot better than the other way around."

The idea is that the "logic" is in your data structures, whereby you build a "rich" domain model, complete with logic and functionality. This is as opposed to an "anemic" domain model, which is just flat data structures (or DTOs) that do nothing more than represent a state of data and have no functionality.

With smart data structures, the code that uses them (which will be in your controllers, as well as various other places) doesn't need to be sophisticated or complicated. It just needs to tell the Models what's going on and direct them to do what they need to do. The Models have all the know-how to actually do it.

This is preferred over "smart code and dumb data structures" where the Models are anemic DTOs (which have their use, don't get me wrong) and all of the logic is in a more procedural format where each procedure needs to have all of the know-how to perform the business task at hand. This leads to, among other things, lots of code duplication.

I hope this helps. As I said, I'm having a hard time understanding the full scope of your question.

Edit: Another thing to consider, since I'm not sure where you were going with the "data is primary" concern. There is a difference between "data structures" and "data persistence" and that difference is absolutely critical here. Your data structures are your Models, enriched with business logic. Your data persistence is the data in the database.

Very often (all too often, if you ask me), these notions are confused in programming. In most auto-generated code and helpful frameworks and all that stuff, "Models" have a tendency to be direct mappings to database tables and simply represent a record in those tables. This isn't always wrong, but it is misleading.

The business logic isn't in the database. It isn't in the flat representation of the data. Sure, the database can contain its own persistence logic (such as referential integrity, triggers, auditing that isn't known to the business logic code, etc.) but it doesn't contain the business processes that you would normally see in a flowchart of the business logic.

These concepts may be breaking out of the mold for any given framework's standard operating procedure. As I said, I can't really speak for the framework. But personally I tend to advocate "good code" over "popular use of a given tool."

I'll provide some of my opinions about the MVC pattern coding. For the lazy programmers it's really easy to mess up the codes between the controllers and models.

Below were my folder structure:

Controllers : should be light and clean, the only thing here is to determine which models or views should be loaded to response the request.
Views: Even thought it can access the models directly, but I prefer to do it through controllers. And keep the html clean.
Models: done all the things but divide into folders.
- Classes/Objects : contains all objects based on database schema.
- Repository/Factory : includes query, insert, update and delete method. Only map one file to one table.
- Services : Business logic, login, logout, or everything which's not related to the database or even join the table together and return the results.
- Utils : Static method for Views based on Repository/Factory.

Hope this help! and welcome any suggestions.

I will say the Business layer is part of the Controller since its consists of all the components that enable the user to interact with both the View and the Model alike. From the retrieval, processing, transformation and even management of application data and business rules.