Proper way to build MVC for my application

Question

I am scraping data from I want to scrape three search engines. In My queries_controller I will have a function search that calls $this->Query->find('$query'). My Model will hand this onto my own Database whose read() funcion will call three functions, searchGoogle($query), searchYahoo($query) and searchBing($query). The return values will be standartized by some helper functions defined within the Database and then be added onto the array that read() returns. My model will simply pass this information onto the controller which will display it in a view. At the same time the controller will write into a MySQL Database all results of my query with an extra model whose write() function it will call.

Is it right that all functionality will be in the database or should the database return the rough content and leave it to the model to standartize it? Woud my model have another model write it to a database or would it be the controller? would I have helpers in the database to do the standartizing and is there something like extends for functions so they all have the same return array? Can I define what an array has to have that my search functions use?

Answer 1

It sounds like you've got an awful lot of abstraction going on here, but I can't tell if it's real abstraction of if you're just using a few terms (e.g. "helper") ambiguously. Generally speaking, your model would talk to your datasource. That datasource could be a database, a service, a flat file or some combination of any/all of those. I regularly use an external service to gather most of the model data and then flesh that out a bit with some application-centric data pulled from a specialized database.

Helpers generally appear at the view level and help you to display the data. My own preferences is for the model to return raw data to the controller which forwards that same raw data onto the view which is responsible for figuring out how to display it. There are exceptions to that flow from time to time, but they're pretty rare in my own usage patterns.

Short version: keep things simple (and within convention). Let your controller handle application flow and application-centric activities (e.g. messaging, session access, etc.), let your model handle data access/retrieval/manipulation and let your view worry about how to display the data returned from the model (through the controller).

Adding more abstraction on top of that is generally just adding unnecessary complexity. Without any real knowledge of your situation, this is only guidance, but I've found it to be generally solid guidance in my own experience.

Answer 2

Keep in mind, the best practice for CakePHP (and most MVC architectures in general) is:

Model = fat
Controller = thin
View = skinny

That being said, putting functionality into the Model is not bad, as long as it is applicable to the data you are manipulating. Think of the Model as handling all of the data specific issues (i.e. storage, queries, manipulation, optimization, etc.). The controller handles all of the Business Logic, and Views manage the display of the combination of the two.

Helpers are designed to facilitate view functionality while elements are reusable views.

As for the rest of your questions, it may be simpler to break them out into individual questions with code samples if you are getting stuck somewhere.

Answer 3

In general you want to avoid having logic in your database. The database should be responsible for returning the data and then the Model will be responsible for doing whatever it needs to. It is much more difficult to scale the database than to add more processing power. Code in the database is much more difficult to maintain in addition to scalability concerns.