Which Code Should Go Where in MVC Structure

My problem is in somewhere between model and controller.Everything works perfect for me when I use MVC just for crud (create, read, update, delete).I have separate models for each database table .I access these models from controller , to crud them . For example , in contacts application,I have actions (create, read, update, delete) in controller(contact) to use model's (contact) methods (create, read, update, delete).

The problem starts when I try to do something more complicated. There are some complex processes which I do not know where should I put them.

1. For example , in registering user process. I can not just finish this process in user model because , I have to use other models too (sending mails , creating other records for user via other models) and do lots of complex validations via other models.
2. For example , in some complex searching processes , I have to access lots of models (articles, videos, images etc.)
3. Or, sometimes , I have to use apis to decide what I will do next or which database model I will use to record d开发者_如何学JAVAata

So where is the place to do this complicated processes. I do not want to do them in controllers , Because sometimes I should use these processes in other controllers too. And I do not want to put these process in models because , I use models as database access layers .May be I am wrong,I want to know . Thank you for your answer .

---

Just a short comment (no solution) AFAIK that is an eternal question - MVC is just a pattern, and as such, is in theory implementable cleanly. In practise, due to limitations set by available tools (such as programming language library contents and UI component interface design..) you have to make local decisions. The important thing is that you aim to separate these...and not have everything in one mess. I take my comment off the air and am left to see if someone has a "final solution".

---

For simple tasks I would write action helpers (e.g. sendNewsletter).

For sophistocated tasks I woud create services (eg. email, auth etc.).

---

In MVC, you should place those things in the model (for reuse reasons for one).

However, in HVMC, you could place them wherever (such as in a controller) and call the controllers from within your application.

---

I would make your controllers simple.

In many ways the model allows you to offload a lot of the complexity that would otherwise occlude your controller code. Its this division of complexity which will make your code more easily understood, and easier to maintain.

personally I try to keep my models resembling real world objects, not databases tables or rows. It makes it much easier if you have made things speak in more readable terms. A single real world object might involve 5 or 6 database tables... And it would be a rather large hassle to speak with 5 or 6 models, when all you want to do is turn on a switch, or pick a flower, or paint an icon, or send a message.

---

What's wrong with a controller using multiple models? Isn't the point of MVC to make the model reusable? In your first scenario, it's perfectly fine to send emails and manipulate other model objects from wherever the "register user" controller code is.

In regard to your second scenario, why can't SearchController use ArticleModel, ImageModel and VideoModel? It's fine to have a controller without a model. SearchController doesn't need a SearchModel class, it just uses the other model classes.

I'm trying not to get into a rant about MVC in web apps, but basically, IMHO the controller is just a high-level list of steps to complete an operation. As a rough example, the "register user" controller code should do each of the following steps in roughly one or two lines of code:

1. Validate the input
   1. If not valid, redisplay the form with an error
2. Create the new UserModel object from the form input
3. Insert the new UserModel object into the database
4. Create/edit whatever other model objects are necessary
5. Send off an email to the new user
6. Display a "registration successful" page

How those steps are coded largely depends on whatever framework/architecture you're using.

---

Keep your controllers clean. For backend processing use Manager classes like MailManager etc..