Results 1 to 25 of 274
Nov 10, 2004, 12:02 #1
- Join Date
- Sep 2004
- New York, NY
- 0 Post(s)
- 0 Thread(s)
Data Access Layer - Is there a real seperation?
This conversation started in the comments of HarryF's Blog, and I thought it would be worthwhile to move here to continue the conversation, since thats what this forum is for.
This started as a response to Tony Marston's very interesting Development Infrastructure for PHP, which I highly recommend as reading even if you walk away disagreeing with his methodology.
To bring you up to speed:
Originally Posted by JNKleinOriginally Posted by Tony MarstonOriginally Posted by CochambreOriginally Posted by Tony Marston
To respond to Tony's question about why I seperated the User and UserMapper class; if you have a User class that performs some business logic that doesn't interact with the database - suppose a hypothetical printUserName() method that just spits out the current $user->username, wouldn't you want a seperate class that mapped a user to the database, either inserting or deleting or what-have-you? Then, if you needed to add more functionality on the business logic end, you would only change the User class (not the UserMapper class) to have another method, suppose printUserEmail(). This way, you can extend or refactor your User business logic (maintaining the same interface), without changing anything about the data access.
This is how I interpret the "seperation of data access and business logic".
Maybe I'm not doing a good job of explaining my logic here - George Schlossangle says it well in his "Advanced PHP" chapter on this very subject (which, again, I recommend). Maybe someone else can clarify?
Regardless, my question to Tony is this - if you have your business logic and data access logic in the same class, can they be seperate? In reference to the business logic, Tony said "Each business entity (eg: customer, product, invoice) has its own class. This identifies the structure of the associated database table..." - I think this is the part I'm having trouble understanding, because where is the seperation of logic if the business entity knows both the business logic and must know the structure of the associated data storage mechanism.
And now, a seperate question - what is the point of a DAO (chose your favorite - ADODB or PEAR DB) that probably won't make it any easier to change what database you're using, since there is inevitably still hardcoded some query that doesn't work the same in mySQL, msSQL, PostreSQL, and Oracle, let alone just two of the above. Just because you execute($query) doesn't mean $query will actually work.