Proper MVC design

[eluser]AtlantixMedia[/eluser]
Hello everybody,

I recently started playing with CI and MVC and decided I will recode my projects which have always been "procedural" in nature. I started with the admin panel. wanted to make sure I'm doing things right. In the admin panel I have a menu with:

Configuration
--Add configuration variable
--View configuration variables
--etc
Sitemaps
--Load sitemap
--View sitemap
--etc
Tables
--Show tables
--etc

to achieve this I'm using one controller called Admin, one model called Admin_Model, and a View. The submenu items all point to functions which are inside the Admin controller. Every access is strictly done in the Model and any input goes strictly through the Controller which does routine checks and passes it to the Model through variables.

now my questions are:

1) should I have different controllers for each important section of the admin area instead of having just one Admin controller? for example, one controller for sitemaps, and so on?
2) I have read that the View is independent on changes occuring to the Model. That is, if a column name changes in the database, the View will still work. I do not understand this as the Model gets database data and passes it to the Controller as an associative array. The View then blends that with HTML but it may refer to array indexes which are actually database table fields names. i.e.: <?php echo $data['Item_ID']; ?> where Item_ID is a table field name. am I missing something here?

thanks

[eluser]gtech[/eluser]
I am still building on my understanding of MVC so don't take this as gospel, but I will have a go..

[quote author="AtlantixMedia" date="1197240331"]Hello everybody,

now my questions are:

1) should I have different controllers for each important section of the admin area instead of having just one Admin controller? for example, one controller for sitemaps, and so on?
[/quote]

I don't think it really matters. Personally I have a controller for each important section, but for me it makes sense to as my methods are quite long. If your methods are only a few lines long then maybe it makes sense to put them in the admin controller. maybe use a bit of common sense and try and keep the code maintainable and readable.

[quote author="AtlantixMedia" date="1197240331"]
2) I have read that the View is independent on changes occuring to the Model. That is, if a column name changes in the database, the View will still work. I do not understand this as the Model gets database data and passes it to the Controller as an associative array. The View then blends that with HTML but it may refer to array indexes which are actually database table fields names. i.e.: <?php echo $data['Item_ID']; ?> where Item_ID is a table field name. am I missing something here?
[/quote]

My interpretation is that when somebody is referring to the view being independent on changes occurring to the model, they mean that the view should not be making alterations to any data (e.g. inserts updates). Its OK for a view to ask a model for information and if a field name is changed in the database then you would expect to have to change a variable name here and there.

maybe you could source where you got your information from so I can double check my understanding.

Its the controllers Job to request changes to the model by calling an insert or update method for example. A controller can also request information and pass it to the view (The view can also request information by calling the model directly BUT it cannot request changes).

[url="http://en.wikipedia.org/wiki/Model-view-controller"][wikipedias take][/url]

you can search the forums for this as its been discussed quite a lot.

[eluser]maadmac[/eluser]

1) should I have different controllers for each important section of the admin area instead of having just one Admin controller? for example, one controller for sitemaps, and so on?

Ditto gtech. Use what makes most sense to you, be careful to avoid premature optimization.

2) I have read that the View is independent on changes occuring to the Model. That is, if a column name changes in the database, the View will still work. I do not understand this as the Model gets database data and passes it to the Controller as an associative array. The View then blends that with HTML but it may refer to array indexes which are actually database table fields names. i.e.: <?php echo $data['Item_ID']; ?> where Item_ID is a table field name. am I missing something here?

No, you've got it -- that's a problem, since the easiest way (least code, anyway) is to use the same table names as view variables. I'm not sure which approach strict MVC takes with respect to the model / view relationship, though... I thought the view wasn't supposed to care where the data came from, not necessarily that it didn't require some naming relationship. That is, you could start using another data source, so long as it had the same table names, etc.

What that means in practice is that, yes, you'll have to change some variable names if you change your table field names, but that's not a huge deal; unless you expect to do a lot of firesale re-naming, it's a minor inconvenience. Your other alternative is to do all the decoupling in the controller: instead of looping through your results and passing them as-is to the view, you could re-name them there in the controller so that the controller-view relationship is always the same. This takes a little extra work, but that means that your dozens of view files never have to change; you would potentially just change one controller file if you changed the model.

For most of my projects I don't bother with it, but if I were building something to be released or I knew would be deployed in uncertain environments that's the route I'd take.

[eluser]maadmac[/eluser]
ADDITION: Did a little hunting around, since question #2 got me thinking. Here's one CI coder's take:

"Try and keep the input to a controller as generic as possible as well, let the controller map form fields onto a model’s properties, that way you con use the model isn’t tied directly to the a specific set of form fields."

From [url="http://www.jimohalloran.com/2007/09/06/how-i-use-codeigniters-mvc/"]How I Use CodeIgniter's MVC[/url]

[eluser]gtech[/eluser]
thanks for the link maadmac, thats an excellent resource. I also like the fact he emphasized that CI is a loose framework and that you can adopt a strategy that suits your needs.

"CI is a loose framework, you’re free to use it however you like as long as it gets the job done for you."

[eluser]AtlantixMedia[/eluser]
thanks for your insight, guys