Is it overkill to put MySQL select statements in a class and CRUD statements in a child class?

Question

I have 2 classes for accessing the database:

MovieDAO - access database using "select" statements only; the purpose is for retrieving data for displaying in the web browser.

and

MovieExtendedDAO (extends MovieDAO) - which is more complete and allows for creating/updating/deleting a movie in addition to the inherited functionality. This class is intended to be used only in the site's administrative area.

I have been told it is overkill to separate it like this.

Is this is a normal way to do things or part of a design pattern? Or is there no real benefit to doing this? My main intention was to simplify things for the public side: a kind of optimization for how much stuff needs to get loaded up and also what kind of things can happen on the public (non-admin) side. Thank you for your comments!

Answer 1

it's not a bad method, it's basically a row data gateway. in that sense i would think of your movieDAO as more of a finder, (same terminology fowler uses), and your movieextendeddao as a gateway (ie MovieFinder, and MovieGateway).

once you start getting more complex domain logic (ie calculating various things about movies) then you can look at some other data access patterns, but your approach seems reasonable for what you're doing.

Answer 2

You should consider why you are separating the classes. If it is for performance sake (not to load a bigger class for simple reads), than you are most surely optimizing prematurely. You should not make such decisions until you can tell from actual data that such a need exists (which in my opinion will never happen. Use APC or some other bytecode cache if you are worried about large classes).

Regarding permissions - this is something that should be application logic, and not be physically separating the methods into different classes. Also, aren't you extending a basic DAO that abstracts such operations? you will not be implementing separate insert/delete/update methods on each model will you? those operations don't vary much and should belong in a common parent class.

I suggest you have a look at some good open-source implementations for database abstraction in PHP, such as Zend_Db (which I highly recommend).

Answer 3

It's not overkill. Sure, there are better ways of limiting access to your code. But what you are doing is separating retrieval of data (an array of records) from modifying data (single record, instance).

Perhaps you could give your classes different, more meaningful, names. Instead of MovieDAO you could use MovieQuery and instead of MovieExtendedDAO you could use Movie. You keep the funct. separated as you have now, but make the classes more self-explanatory.

Answer 4

The main problem I see here is that you are mixing permissions ( Control ) with database access ( Model ). I goes against the Model - View - Controler architecture but no I am not saying everybody needs to use it. It is a kind of complex pattern. It may have advantages over your solution. Does a change in your permissions affect your class model? I think so.

Appart from MVC there may be other ways to control access. At the database ( by users, for example ).