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