Question

I’m really lost on this case. I am trying to apply a custom MVC framework to my web application. The confusion rises from organizing the SQL queries. OK, here’s the case:

UserRepository, ThreadRepository and PostRepository are all repositories that hold the SQL queries relevant to them. For instance, in the ThreadRepository I have the getThread function which retrieves a thread from the database by its ID, in UserRepository I have getUser function and so on…

However, say I am in the page that I have to retrieve a post, its thread and its submitter. When I apply the logic above, I’ll have to call getUser, getThread and getPost explicitly. If I was not using MVC, then I would probably create an SQL query like this:

SELECT * FROM user
LEFT JOIN thread on userid = tuserid /* Thread user id = user id */
LEFT JOIN post on pthreadid = threadid /* Post thread id = thread id */

And voila, I would retrieve all the required stuff in a single query. But in this case, even if I write such an SQL in which repository should I place it? I mean, its awkward to see a code like the following:

$pr = new PostRepository();
$user = $pr->getPostAlongItsThreadAndItsSubmitter($postid); 

C’mon look at this, first of all the code is not clear. You’ll have to look to PostRepository to discover that the user is being retrieved from there, which is really not likely the first place you’ll look as a third person. Second of all, it’s not scalable. In future, as the application will grow I’ll have to apply the same logic for, say, when retrieving the user statistics, or user friends, or user messages. Then it will be all complicated.

On the other hand, if I call the functions mentioned above (e.g. getUser) to retrieve a post, its thread and submitter separately, then it means that I’ll have to sacrifice a lot from the performance since I am making (at least) three different mysql queries to retrieve some basic stuff that could be successfully managed by a simple join. (Here I assume that 3 queries are slower than a simple join, that’s what I’ve read when I searched)

So finally, what I really ask here is how to organize the business logic so that I can retrieve a post, the thread that it belongs and its submitter easily (actually, this can be either hardly as far as it satisfies the options below) while the process is:

1. Crystal Clear for third party people (e.g. other developers that will be recruited to the team)
2. Performance Wise
3. Scalable

All comments and opinion are highly appreciated.

P.S: I know this is not a what is this or why is this question, but please, I really need help on this case so don’t click on close just because it’s not a question that can be answered in a sentence. Please ask me to improve the question if necessary.

Answer 1

First of all this looks like that your database abstraction does not abstract joined tables: You’re missing an implementation inside your db abstraction that is equivalent to the sample SQL SELECT ... JOIN query.

So I would locate this as your basic problem.

As you’re using a database abstraction, you can either complain about that each abstraction layer comes with a price (three db queries instead of one) or learn a lesson here: Each abstraction comes with a price.

And no: There is no silver bullet in design.

So if you can solve your problem by educating new developers (e.g. you actually have specification for the software you write, right?) what’s so bad about it? This will do the job.

In the end, you will have one function somewhere that is executing your JOIN SQL query. However you name it. And that function will return the three objects that are queried from your data store. However you turn it.

The benefit of abstraction is, that inside your business logic you don’t need to deal with the data store, but you just use your (maybe you find a better name for it) function:

$pr = new PostRepository();
$user = $pr->getPostAlongItsThreadAndItsSubmitter($postid);

But I wonder why you use the PostRepository to return a $user, maybe that’s just because you couldn’t really make up your mind.

Anyway your data-store abstraction seems pretty redundant, as all classes are similar named only differing for their type. Maybe you just have a DataRepository and probably a DataQuery object which methods can return either single objects (Recordset like Pattern) or lists of those objects.