MVC CRUD Architecture debate

[eluser]spyro[/eluser]
I have seen two different styles of MVC CRUD when it comes to standard operations.

The first is the controller/action method. ( Ex: Contacts/List ) This means that you build a view for every controller.

The second is action/controller ( Ex: List/Contacts ) For this you can pass in meta data to build the list view but it makes customization a little harder.

Which do you use and why?

[eluser]Xeoncross[/eluser]
CRUD = Create Replace Update Delete. This is a way of interacting with a data source.
MVC = Model View Controller. This is a way of managing code.

They are two different things. Most MVC's use a CRUD model when working with a data source like a DB. Actually, they all do - that is the point of "M" in "MVC".

[eluser]spyro[/eluser]
I understand that they are different but the can be grouped when they work together which is relative to the question at hand.

Let me explain a little further.

When building an MVC applications CRUD functionality there are two common ways that I see it done. The first is action first and the second is controller first.

Examples:
For the R in CRUD you may list the data therefore you can do
list/section||controller ( Ex: list/contacts - normally related to a controller )
or
controller/list ( Ex: contacts/list )

This is also the fact for the D in CRUD delete/section||controller controller/delete.

The question is, which way do you choose an why.

[eluser]Xeoncross[/eluser]
I don't think you understand.

When calling a page using any kind of MVC framework you can only do one thing - call the controller/method you want and optionally pass it data. The controller then can (optionally) load/interact with a Model which is the CRUD object you use for things like databases. The controller method can also load a view and display data (like results from the model).

[eluser]Jamie Rumbelow[/eluser]
RE @Xeon's comment, it's not even that. Load order is defined by the framework, not the design pattern. The MVC architecture can provide suggestions, but it's up to the framework to implement it.

[eluser]spyro[/eluser]
[quote author="Xeoncross" date="1236466564"]I don't think you understand.

When calling a page using any kind of MVC framework you can only do one thing - call the controller/method you want and optionally pass it data. The controller then can (optionally) load/interact with a Model which is the CRUD object you use for things like databases. The controller method can also load a view and display data (like results from the model).[/quote]

I fully understand what you are saying. Admittedly, my word usage may have not been 100% accurate in my presentation but I really wasn't focusing on what we are discussing.

[eluser]Colin Williams[/eluser]
Your controller/action paradigm is incorrect. What I think you intended to discuss was object/action, action/object. Controllers can follow either. You can write action-oriented controllers, so you have an Add controller, an Edit controller, a Delete controller, etc. Or, you can write object-oriented controllers. I think the latter is better/more organized, but there are benefits and drawbacks per each.

[eluser]spyro[/eluser]
[quote author="Colin Williams" date="1236478840"]Your controller/action paradigm is incorrect. What I think you intended to discuss was object/action, action/object. Controllers can follow either. You can write action-oriented controllers, so you have an Add controller, an Edit controller, a Delete controller, etc. Or, you can write object-oriented controllers. I think the latter is better/more organized, but there are benefits and drawbacks per each.[/quote]

I think that I have already more than agreed that to word usage of controller/action is incorrect in previous posts. But everyone seems to understand my question.

Thank you for the clarification but I am more interested in to which approach you think is best and why.

[eluser]Colin Williams[/eluser]

I think that I have already more than agreed that to word usage of controller/action is incorrect in previous posts

I was only half sure of this, but my apologies for spelling it out even further.

The main idea of OOP is that we treat data in the application like real-world objects. We can look at the world and our applications as being comprised of objects that have properties and perform actions. Flip the perspective and say that the world and our applications are comprised of actions that happen to, or on behalf of, objects which have properties. In my opinion, the former is a.) more intuitive and b.) better organized.