Data abstraction layer design

[paralyzah]

Hi, I'm looking for the best way to design the data abstraction layer of my application. The application is using the MVC design, so this'll be the model. Here's what I have so far. I'd like some pros and cons, and maybe alternative solutions.

 

At the bottom I have an adapter. Actually I only have one (MySQL, using the standard MySQL extension) and a half (SQLite, using the standard SQLite extension) so far. I'm going to need MSSQL too in the near future.

 

The adapter is fabricated by a factory method like this:

 

$Connection = Connection::factory("mysql://user:password@host:port/database");

 

It has basic methods like query(), escape(), getInsertKey() and so on. In addition I have an extended version of each adapter which has methods like getDatabases(), getTables(), createTable(), renameTable() and so on.

 

So this is the adapter.

 

On top of the adapter i build getter and setter classes which i guess you could say is the actual models (the adapters are part of the framework). I have two classes for most tables. One representing the entire table and one representing one specific record. Heres an example:

 

$Users = new Users ( $Connection );

$Users->create()->set( "Email", "user@domain.org" )->set( "Nickname", "paralyzah" )->update();

 

The second line may be confusing. Most methods in the record class return itself. So, what's happening here is I create a new object representing the entire table. I create a new record, which is not actually created in the database yet. I set some values of some fields. And last, I update it. Now it's created in the database. Since this is a new record, the update method will figure out that and use INSERT instead of UPDATE.

 

The point is anyway that I have two classes for most tables, and they are merely getter and setter classes that takes care of the SQL statements needed.

 

Here's a specific question: In the setter methods, I validate the data. i.e. If it's a string I escape it (to prevent SQL injection) and if it's an email this is the place I make sure that it is. If the data doesn't validate, an exception is thrown, so I can handle that some place else. Is it a good or a bad idea to do this kind of validation here?

 

This is basically it for the data abstraction layer.

 

Above this, I'm in the business logic layer. Here I may have other classes that do business logic related to users (or whatever). i.e. I usually have a method like hasAccess() which determines whether a user has access to a specific area (or unit of code to be correct):

 

if ( $SignedInUser->hasAccess( 2 ) ) { // 2 is the key for the access area.

// Access granted.

} else {

// Access denied.

}

 

What other ways are the to solve this? If I were to use PDO, would that be just another adapter or would it be wise to follow a totally different design pattern?

 

Thanks in advance guys! Hope this sparks a great debate!

[448191]

Is it a good or a bad idea to do this kind of validation here?

 

I think you're asking if it is a good idea for a business object to validate its input. I'm personally a bit torn about it because on the one hand you want your objects to be defensive, but on the other hand having to add validation to your business object puts some requirements on them, something you'd rather avoid. It's a close call, and perhaps in some scenario's the other way around is more advisable, but I'd recommend validating at the point of input collection to avoid laying the burden of responsibility for validation on the business objects. On the other hand the business object knows best how its values should be validated.. I concede, it's a draw.

 

 

What other ways are the to solve this? If I were to use PDO, would that be just another adapter or would it be wise to follow a totally different design pattern?

 

Thanks in advance guys! Hope this sparks a great debate!

 

You'll have to tell us where you find to be a problem first. And your PDO question is not making a whole lot of sense. As I understand you have created an adapter interface for database driver interfaces (ironically a lot like PDO). But PDO itself is just another interface to driver interfaces so where do you see the need to redesign anything?

 

 

[paralyzah]

your PDO question is not making a whole lot of sense.

 

To be honest, I haven't read my self up on what PDO is or does, so to me it's basically a buzz word. And that's kinda why I'm asking. I thought maybe there would be any benefits using PDO? And that if I were to use it, the best way to use it in an existing application (built with my framework) would be to create a new adapter using the same interface as my other adapters?

 

But PDO itself is just another interface to driver interfaces so where do you see the need to redesign anything?

 

If I were to create a new adapter using the same interface as my other adapters, I wouldn't need to redesign anything. I was just asking if there would be a better way to implement PDO. But as I said, I'm totally blank regarding anything PDO.

 

However, what I was really asking (or trying to ask) was if this is the way to write the data abstraction layer, and if this is it? Or should there be more to it? Or are there other ways, and maybe better ways to do it?

 

And sorry for asking, because it may come as a stupid question, but what's a business object? Is it what I called a getter and setter class?

[corbin]

Perhaps a comparison with PDO would be better than words....

 

 

The concept behind PDO is essentially the same as your interface/adapters design.

 

 

There's a main PDO class, and when you make an instance, it essentially returns an adapter.

 

http://us3.php.net/manual/en/intro.pdo.php

[448191]

So..  You can just use your adapter interface to provide access to PDO functionality, same as your did for the MySQL extension.

 

Business (domain) objects: http://en.wikipedia.org/wiki/Business_object_(computer_science)