controller naming convention

[RonR]

Hi David,

First of all, you wrote a great book. Its clear, well organized and very helpful. I have a question about controller naming conventions. On page 31 you mention that controllers MUST match a database table name. My question is why (hopefully I won't be embarrassed by an obvious answer)? We generally follow that convention, but not always. For example, we have a search function that looks at up to 20 tables, so we named the controller "search" even though there is no "search" table in the DB. Second question, what can go wrong if you do not follow that convention (as we have)? Thanks in advance!

Ron

[davidgolding]

This is a good question. Frankly, I've noticed that a lot of Cake developers, and other non-Cake ones that use MVC, run into this aspect of how to use the controller. Remember one very important point about Cake--it's not only a nice set of features, it's first and foremost a way, a convention, of building web apps. I promise you as you go through the book and the framework that you'll find many ways that you could build the various elements of a Cake app in your own way, without considering the conventions, and the app will still work. You won't even necessarily cause the app to break down at some future point for disregarding a convention or two. But, you'll at least be naming and using various Cake resources in your own way, and that may cause semantic issues as you involve others or get support for the project.

Two aspects of any application's architecture are at work in a question like yours. First, there's the concept of encapsulation, which is a fundamental component of working in any object-oriented programming language. What you have with Cake is more than a set of libraries and instructions. You have customizable objects that do specific things. While you can technically use a boat, car, plane, or train to get from point A to point B, you can only use a car on roads, a train on rails, a boat on water, and a plane in the air. Yes, a plane can actually drive on the ground, but its main design is as a method of travel through the air. And a car can make it on train tracks, but it's designed for roads. You get my point--different objects in Cake can overlap, and in some cases, to a larger degree than my analogy above, but there is a main design to each class object, and when you build your own extensions from Cake's classes, you ought to stick with the architecture. If you haven't seen this yet, you will as you build more complex apps. I know I've been able to produce more lightweight apps the more I've kept to the Cake structure paradigm.

Second, there's the concept of modular programming, or a separation of concerns. This method is a software design technique used by Cake throughout the entire core that has some key benefits. By forcing there to be boundaries between modules in the application, like your controller and model classes, maintaining the application is improved.

If using a controller to handle only database methods doesn't yet seem clumsy or sloppy, then keep working with Cake's best practices, and see if you begin to notice advantages. They may be hard to put a finger on, but they're there, and I've noticed significant gains in maintaining apps as well as involving other developers with the project as I've stuck with these concepts.

[Paddy]

Hey David,

thanks for your comments on Frank's question.
Still it would be very interesting for me to hear more about the correct implementation of this specific search-controller example. Would a search-component be the way to go?
I'm sorry if I missed something or the solution seems too obvious.

Paddy

[davidgolding]

Well, if you were to use a component to run searches, getting it to connect to the database would be tricky. You'd have to add something like

---

App::import('Model',array('table 1','table2'));
$table_1 = new Table1();
$table_2 = new Table2();

---

to get the model classes in the component. Then, from there you'd have to run your find methods with these model objects in the component, something like

---

$set = $table_1->find('all',array('conditions'=>array('name'=>$query)));

---

But, here's the problem... You have to manually supply the names of the individual models. This, right off the bat, is the red light that discourages me from using a component to run searches across the database. See, the component is supposed to be portable. This doesn't mean that all of its methods have to be extremely generic, but in general, the component ought to be "installable" in any Cake application, and with minor configurations, still work.

True, you could supply properties that would store the model names, and then have the controller manually provide the names of the models in some fashion, but you can see that all of this is being done without the model. And as a rule, all database interactions ought to be done in the model. This better encapsulates the class objects to have them perform their fundamental operations, and the component is mainly designed to handle portable business logic, not data handling like the model. Not to mention the Cake dev team encouraging developers to leave the database totally out of the component.

Or, here's another scenario... Suppose you use the App Model to run searches across the different models. You could build a search() function in the App Model that any of the models could use. This function would perform the same query, the only thing that would change would be the child model calling for the search. Or, if indexing is your thing, then my initial thought is that this would be best accomplished with a behavior. (For lack of time, I'll just encourage you at this point to check out Chapter 14 on DataSources and Behaviors; also check out my chapter on Components and Utilities for a discussion on when to use components.)

These are my first thoughts, but admittedly, you're touching on a very technically demanding topic. Heck, Google has made billions with their own forays into search methods; I wouldn't presume to know everything about how to better index your site's database and search it, but I would say that to only do this in a controller is likely going to worsen the order of the app's structure.