Some questions concerning MVC pattern in a CI application

[eluser]Crafter[/eluser]

Now, the question is not, when to use more than one controller, its more like: what should a controller contain and what motivates the creation of another controller?

A controller should represent a business object that you can represent in your application. For example customer, blog, product, user ....

Each object has actions that are allowed. For example, a product can be created, modified, looked-up, booked, purchased, returned, .... These actions will be your controller methods, and be accessed as
http://mydomain/product/create/
http://mydomain/product/reserve/
http://mydomain/product/buy/

Your controller method will contain the details of who, why etc. For example, only a staff member can create() a product, a customer can only buy() is there is sufficient stock, and so on.

Other kind of dilemma I had was where to draw the model-controller and controller-view boundaries.

In order to consider your model, you need to visualise a scenario where your data is stored and controlled by a party that you have no control of (for example another company). In this case, they keep your data, understand where what is (not necessarily what it means). In addition, the relationship between you and the data-handling company must be structured and agreed beforehand, so that they can give you the data that you require.

That same thinking goes into the view. Here you pass the processed data to some party that presents them as they need to. You are not interested in how they ensure that a cellphone, Mac, and PC all see the same information - that is their problem.

At the same time, this sets the rules for the interaction, The data company gives you the product details, you determine if you want to sell it and what to say to the customer. The customer facing company gets your decision and presents it to the customer. In the same breadth, the data management party is not allowed to pass information directly to the data presentation company.

So the MVC paradigm (theoretically) allows for the total separation of your applications into layers, which function and inter-relate in a structured and independent way. In reality, while you might be all those parties, during design time, you need to put on those different hats.

Regards
Pradesh