Data Access Layer - Is there a real seperation?

[MickoZ]

1. For the Enter behavior I am well aware of it. I just found it weird that it did that... actually it should use the first button within a form (but then I have not looked the standard). Hehe... but your user may expect that, but I am sure just some javascript and hop your user will be happy.

2. A question Tony.

Is an User and a List of User the same thing?

I do not say to do separate object for all, but *conceptually* a User is an User and a List of user will be a kind of list. There was some person who give some "rule" (best practice?) for concept like inheritance and it says something that the child is a kind-of parent. It was very clever from what I think of it. I believe that you use that anyway. You modelize a Table and do a KindOfTable (might be an answer for your sceptic).

Also how flexible is your approach?

Ex1: An User having a list of addresses.
Ex2: We Delete Object A, which has instruction to Delete its child (therefore all B) but when wanting to delete B, B has a constraint that you cannot delete its child.
Ex3: Same as Ex2 but when deleting B, B should delete in cascade.

class A
{
listOfB : B
...
}

class B
{
list of C : C
...
}

class C
{
...
}

The way you have done this, I believe you called directly DELETE from TABLE where... (for the relationship)...

But then if there is a 3rd level of relationship, your generated query won't work. I guess like any framework we have limitation and exception... I have looked just last night and I hope I don't get it wrong about the behavior of the example you shown.

but if A.delete() delete all its relationship first, like:

foreach (listOfB as b) b.delete

and b.delete delete relationship, etc.

Are not we making it more secure...

Of course you like to do all the developpement by yourself, therefore you will probably adapt your solution for this, but feel free to answer me about the way you did your database_table how that situation will be handled.

I'm pretty curious... I like a lot of the idea you give... I read some article and I am sure we can discuss for decade about them ;-) I will try to focus on those points for now.

[MickoZ]

Also I don't know Tony, but if you guys runned in the same about being bold about your opinion or your way to do and if you are the kind of guys that easily see problem in things... then you can understand Tony to not feel bad to criticize. In fact a lot of people criticize him and I am sure if we prove him wrong on some stuff or we just bring up interesting point, that beside complain, [he mights write a poem (!!!) and] use some of our stuff to improve his, but then if our comments are not good, he is right to argue about it... this can go into an endless loop for some people thought

I am also wondering if you have counter example or limitation of your design... sure we like to defend our idea, but we have all some kind of limitiation (i.e. we build screen that way and cannot that way), sorry if you already documented that, just wondering if you did Tony.

[Version0-00e]

I wasn't being critical in my view, just trying to get to the facts

Tony, I wasn't referrering to you being arrogant on the point of encapsulation, but on the point of bumping off Lastcrafts post.

Lastcraft has helped out a lot of people on these boards and for the most part, 99 percent, Lastcraft makes sense of OO Programming where as the rest of us are still unsure in some areas.

A 'List of User', wouldn't that be more like a collection?

[Brenden Vickery]

Well, if that is the case then you do not have a true domain model (at least in the PoEAA sense). Which is fine. Your implementation is closer to the ActiveRecord pattern which mixes domain logic and data access logic.

JT

After looking at Tony's example application, he uses no domain model that I can tell. Tony uses a kind of Table Data Gateway with a layer supertype that also acts as a sql query builder that uses meta data described in the TDG.

Using the User example, Tony doesnt make User objects that have properties like name, dob, etc. The User objects are only concered about data access and validation of data being put in the database.

[MickoZ]

His way to do stuff is "interesting" and like some people said they can compare it with other pattern (I am still trying to find an interesting, clean and efficient way to persist date withouth having to add gazillion of rule, maybe those data mapper will help me, etc. but it is a subject that interest me a lot). I am thought concerned that the way he does stuff is not going to be 100% flexible (feeling, but then other have this feeling and Tony seem to be able to defend its way to do thing and show how it works). But as with all framework we have a limitation of how we handle thing, a lot of us (I hope) wish to find the perfect solution sometime, that one that will allow you to handle it any way (multiple form in same screen, multiple way to handle), there is surely solution for all problem and lot of good one anyway.

[MickoZ]

Tony said he has used this in big project, is it multiple project?

How you would handle simple case where like we have to do computation with some attribute? (I readed the FAQ last night but maybe I missed stuff)

Object A
{
attrib1
attrib2
getAttrib3 () { using attrib1 and attrib2 }
}

Anyway we can ask a lot of question I guess and you have probably answered them ;-)

There is also always object that does something that is not persistant with other object...

[lastcraft]

Hi...

...the term 'encapsulation' is defined as...

You'll excuse me if I don't go searching an entire site for one out of context quote . The problem with quoting a beginner's tutorial is that you will get a deliberately simplified picture. An attitude that claims expert status on the basis of quoting a beginners tutorial is something I won't even go into on what is normally a very polite forum.

How you choose and name a class is a very complex design problem. Everything after that is easy. You may have an idea that the piece of code you are writing is something to do with users, but your program needs to be more precise. You have to decompose that vague idea into specific roles to which you can assign responsibilities. A User could also be described as Person plus AccessKey for example (this is actually advisable, but that's a whole other topic). Immediatley we have decomposed User into more refined classes just by taking a different viewpoint. No different than if we split it into User and UserMapper. Your concept of a class is rather naive.

Here are all of the GOF design patterns that would break encapsulation according to your imaginary "rule": AbstractFactory, Builder, FactoryMethod, Adapter, Bridge, Composite, Mediator, Memento, Strategy, Visitor.

To list all of the enterprise patterns that you would not be able to use would take all day. From the top of my head that is a large part of Fowler, Nock, Evans and Beck and that's just from looking behind me at my bookshelf.

There is nothing in the principles of OOP which says that different aspects of an object must be contained within different classes, in fact it states quite the contrary.

There is nothing to say things have to be split into classes any more than there is your imaginary rule that they cannot. It is often convenient and more flexible to do so.

Therefore I consider your opinion to be totally wrong.

It's not a matter of opinion, it's a matter of depth of understanding. That's a lot of hard work.

I would never dream of claiming that one personal form of layering was the correct architecture for every site and problem. I would consider it silly, because I know the real world is a lot more subtle and complex than it first appears. When I approach a site architecture problem I come armed with a whole bunch of solutions, which I gather voraciously, ready to weigh the pros and cons of each. I don't look for the first quote on the web that I can find, misunderstand it, and then use it to eliminate whole families of solutions.

yours, Marcus

[Tony Marston]

Encapsulation is about hiding implementation, which includes data. There is no requirement for every aspect of the "User" concept to be in a single class.

Encapsulation means that the class must define all the properties and methods which are common to all objects of that class. All those properties and methods must exist inside a single container or 'capsule', and must not be distributed across multiple locations.

There is nothing in the principles of OOP which says that different aspects of an object must be contained within different classes, in fact it states quite the contrary. Therefore I consider your opinion to be totally wrong.

Now, that is arrogance, and as one person after following many posts by lastcraft, I'd have to disagree with your statement Tony.

Lastcraft may have provided helpful posts to other people in the past, but if he makes a statement which is factually incorrect, and I have the audacity to say so, then I am immediately accused of being arrogant.

[Tony Marston]

Is an User and a List of User the same thing?

I have a User class which contains a getdata($where) method. The number of user records returned depends on how many meet the selection criteria provided in the $where argument. What comes back is an array which may contain any number of rows, and each row may contain any number of fields. I do not bother to have separate methods for 'single' user or 'collection' of users as I deem it unnecessary.

[McGruff]

As a user, I don't want to read about who's in a huff with whom about what.

I do want to hear people argue their position, politely, on its technical merits, and to attempt to reach some kind of conclusion which others can learn from.

[JNKlein]

Hmm, seems like people are getting in flame mode here. Lets try to keep it nice No highjacking of my thread!

Anyway, about this encapsulation usage - where do you draw the line? When does your User class begin to contain too much and become a "god" class. Why don't you have your View and layout properities within the User class? (I know the answer to that question - just posing it as a hypothetical given the nature of encapsulation.) And so on ... after all, isn't your whole application one entity that could be stuffed into a single class?

How do you get your head around a seperation between data manipulation (insertRecord() in User class) and business logic (printUserName() in User class) within the same class. In a related question - how do you structure your library to account for this combination?

[Tony Marston]

Also how flexible is your approach?

Ex1: An User having a list of addresses.
Ex2: We Delete Object A, which has instruction to Delete its child (therefore all B) but when wanting to delete B, B has a constraint that you cannot delete its child.
Ex3: Same as Ex2 but when deleting B, B should delete in cascade.

All delete constraints for a table are defined within the $relationship array within the subclass for that table. When attempting to delete a record the contents of this array is processed by standard code according to the constraint type:

• Restricted - do not delete the parent if any children exist.
• Delete - delete all children as well as the parent.
• Nullify - set the foreign key on all child records to null.

Note that the delete constraint is set on a (child) table by table basis, so it is possible for a parent to have multiple child tables, each with a different constraint, and they will be handled accordingly.

The reason that I manage the delete constraints within my code and not the database is because:

• I learned my craft on databases that did not deal with foreign key constraints, so I had to do it in the code.
• Because it is handled from the contents of the $relationship array I have the ability to change the rules at runtime should the need arise. This is something that you cannot do if those constraints are managed by the database.

[MickoZ]

I have a User class which contains a getdata($where) method. The number of user records returned depends on how many meet the selection criteria provided in the $where argument. What comes back is an array which may contain any number of rows, and each row may contain any number of fields. I do not bother to have separate methods for 'single' user or 'collection' of users as I deem it unnecessary.

I was just asking a question independantly of your architecture. What you return are result. Can I dare to say ResultSet withouth thinking much.

But I guess by saying an User and Collection you answered my question, which by asking it was an obvious answer!

[seratonin]

After looking at Tony's example application, he uses no domain model that I can tell. Tony uses a kind of Table Data Gateway with a layer supertype that also acts as a sql query builder that uses meta data described in the TDG.

Using the User example, Tony doesnt make User objects that have properties like name, dob, etc. The User objects are only concered about data access and validation of data being put in the database.

I can definitely see how he is using it as a Table Data Gateway. I guess it is more of a naming thing that was misleading me.

JT

[MickoZ]

All delete constraints for a table are defined within the $relationship array within the subclass for that table. When attempting to delete a record the contents of this array is processed by standard code according to the constraint type:

• Restricted - do not delete the parent if any children exist.
• Delete - delete all children as well as the parent.
• Nullify - set the foreign key on all child records to null.

Note that the delete constraint is set on a (child) table by table basis, so it is possible for a parent to have multiple child tables, each with a different constraint, and they will be handled accordingly.

The reason that I manage the delete constraints within my code and not the database is because:

• I learned my craft on databases that did not deal with foreign key constraints, so I had to do it in the code.
• Because it is handled from the contents of the $relationship array I have the ability to change the rules at runtime should the need arise. This is something that you cannot do if those constraints are managed by the database.

Well I don't know if your "article" is exactly your application code, but when I look at that code (correct me if I am wrong) from the part2:

         case 'delete': 
            // delete all related rows
            $where = NULL;
            foreach ($reldata['fields'] as $one => $many) {
               $where .= "$many='$fieldarray[$one]' AND ";
            } // foreach
            $where = rtrim($where, ' AND');
            // set up query to update the database
            $query = "DELETE FROM {$reldata['many']} WHERE $where";
            $result = mysql_query($query, $dbconnect) or trigger_error("SQL", E_USER_ERROR);
            break; 

I am concluding that you delete all children of a parent and you do so explicitely with an SQL query, you are not talking to the relationship "table object".

What happen if with those table we try to put relationship rule for deletion within your framework:

table a
{
  id // don't begin a convo with id naming! ;-) we can advocate both side
     // the goal is to understand each other for the topic we talk about ;-)
}

table b
{
  id
  a_id
}

table c
{
  id
  b_id
}

table d
{
  id
  c_id
}

table n
{
  id
  {n-1}_id  //etc.
}

Won't it be smart when you DELETE a table_b to look into the relationship data for table_b before deleting it with a DELETE query?

I don't want to put constrain about table_n in table_a... and I have not see that in the article, maybe it is within your code

Sure in real-life, there is probably not gonna be 100000 deep level of relationship. But I am pretty sure we can easily come up with more than just 2 levels.

Can you concretely explain to me how that work concretely within your framework? Have I missed something or that is not something you think will happen? A limitation? etc.

[Tony Marston]

I am also wondering if you have counter example or limitation of your design... sure we like to defend our idea, but we have all some kind of limitiation (i.e. we build screen that way and cannot that way), sorry if you already documented that, just wondering if you did Tony.

Asking if there are any limitations in my design is a difficult question, but in all honesty I can only say that I have not met any yet. Bearing in mind that what I have developed is an infrastructure for building web applications which is not as complicated than some other areas (like process control, cad-cam, et cetera) then then that is not as glorious as it sounds.

I have been building non-web applications for over 20 years, and this experience has enabled me to see transaction patterns which occur time and time again. From these patterns I make templates from which I can generate new transactions very quickly. If you look at my list of UNIFACE templates you will see that they are very similar to my PHP templates.

I have taken my entire UNIFACE development environment and converted it to PHP, and although the look and feel has changed, all the functionality is there. I have even added in a Role Based Access Control module, an Audit Log module and a Workflow module, and believe it or not I have even managed to emulate the Tree widget.

On the rare occasions that I come across something I want to do which cannot be done within my existing infrastructure, I simply design a new module to do it. That is the benefit of having a modular design, something which I learned decades ago.

[Tony Marston]

How you would handle simple case where like we have to do computation with some attribute?

As an example take the PERSON table which has fields called FIRST_NAME and LAST_NAME. There may be occasions where I want to show these two values in a single field which I shall call PERSON_NAME. How can this be done?

• By constructing the field within the sql SELECT statement.
• By constructing the field within my PHP code (example below).

    function _cm_formatData ($fieldarray) 
    // perform custom formatting before values are shown to the user.
    {
        if (!isset($fieldarray['person_name'])) {
            // merge first_name and last_name into person_name
            if (isset($fieldarray['first_name']) AND isset($fieldarray['last_name'])) {
                $fieldarray['person_name'] = $fieldarray['first_name']
                                           . ' '
                                           . $fieldarray['last_name'];
            } // if
        } // if
        
        return $fieldarray;
        
    } // _cm_formatData 

If I wished to take UNIT_PRICE and QUANTITY and calculate EXTENDED_PRICE, then I would use the same technique.

[Tony Marston]

...the term 'encapsulation' is defined as...

The problem with quoting a beginner's tutorial is that you will get a deliberately simplified picture. An attitude that claims expert status on the basis of quoting a beginners tutorial is something I won't even go into on what is normally a very polite forum.

Whether you are a beginner or an expert the three fundamental principles of OOP, that of encapsulation, inheritance and polymorhism, simply do not change. What I see happening is that some people are deliberately adding in unnecessary layers of complexity, which, as a follower of the KISS principle, I avoid like the plague.

As for those design patterns you quoted (yes, I do have a copy of the GoF book) you must remember that they are guidelines only and may be implemented in many different ways and many different languages. I write code that works, and if it manages to meet the description of one of those patterns then fine, but I do not go out of my way to pick a pattern and then implement it.

I'm not saying that your architecture is wrong any more that I'm saying that my architecure is right. All I am saying is that my architecture is different, and it works.

[MickoZ]

Reply for your person_name example:

Then if there is anything that is heavy computation, is that done a lazy way? Or each time you do a query?

For example an application I do right now will in the future have to make complicated choice based on criteria. A user have some set of preference (that can change), we will give him result one week, then the following week we can give him result that will depend on the preceding week % of fit of some choice. I will involve a lot of computation and possibility and level of tolerance. Anyway I am not being as much concret there and I cannot 100% for now about that project.

Just thinking of unity_price * qty in a shopping cart... then you might have to get a total... it won't always be list/add/modify/delete problem even thought a vast of the work with data management are that way thought ;-)

I guess you are not only dealing with persistant object in your design.

[Tony Marston]

Anyway, about this encapsulation usage - where do you draw the line? When does your User class begin to contain too much and become a "god" class. Why don't you have your View and layout properities within the User class? (I know the answer to that question - just posing it as a hypothetical given the nature of encapsulation.) And so on ... after all, isn't your whole application one entity that could be stuffed into a single class?

How do you get your head around a seperation between data manipulation (insertRecord() in User class) and business logic (printUserName() in User class) within the same class. In a related question - how do you structure your library to account for this combination?

In my User class I have the getData($where) method which returns data to the calling script, which in my architecture is a page controller. What happens to the data after it has been returned to the controller is irrelevant as far as the User class is concerned. The controller has control of the data and may render it as an HTML document, a PDF document, or a FAX or an email or whatever depending on which view it calls. This is what I consider to be 'separation of logic' that everyone seems so concered about. Am I wrong?

When it comes to the insertRecord() method my architecture works as follows:

• My INSERT controller receives data via the POST method and passes it to the business layer object (and it could be any object from any class) via the insertRecord()method.
• The business object will validate the contents of the passed array according to its own internal rules, and if an error is found it will return controll to the controller with an array of error messages.
• If there are no errors the business object will pass the data and the table structure to the data access object so that it can generate the necessary SQL statement to insert that data into the database.

My updateRecord() and deleteRecord() methods work in a similar fashion. Simple yet very effective.

[Tony Marston]

After looking at Tony's example application, he uses no domain model that I can tell. Tony uses a kind of Table Data Gateway with a layer supertype that also acts as a sql query builder that uses meta data described in the TDG.

Using the User example, Tony doesnt make User objects that have properties like name, dob, etc. The User objects are only concered about data access and validation of data being put in the database.

I can definitely see how he is using it as a Table Data Gateway. I guess it is more of a naming thing that was misleading me.

It would appear that we are each reading from a different book written by a different 'expert' in which the same concepts are given different names, or different concepts are given similar names. No wonder we are all confused! I personally have never heard of a 'Table Data Gateway ' and wouldn't know one if it crawled up my trouser leg and bit me in the a*se (pardon my French!)

[Selkirk]

How you choose and name a class is a very complex design problem. Everything after that is easy.

At the risk of going off on a tangent, I give you a quote from the Wizard of Earthsea:

"You are a very young wizard," the dragon said, "I did not know men came so young into their power." He spoke, as did Ged, in the Old Speech, for that is the tongue of dragons still. Although the use of the Old Speech binds a man to truth, this is not so with dragons. It is their own language, and they can lie in it, twisting the true words to false ends. . . "Is it to ask my help that you have come here, little wizard?"

"No dragon."

"Yet I could help you. You will need help soon, against that which hunts you in the dark . . . What is it that hunts you? Name it to me."

"If I could name it -- " Ged stopped himself. . . .

"If you could name it you could master it, maybe, little wizard . . . Would you like to know its name?". . . .

"But I did not come here to play, or to be played with. I came to strike a bargain with you."

Like a sword in sharpness but five times the length, of any sword, the point of the dragon's tail arched up scorpion-wise over his mailed back, above the tower. Dryly, he spoke: "I strike no bargains. I take. What have you to offer that I cannot take from you when I like?"

"Safety. Your safety. Swear that you will never fly eastward of Pendor, and I will swear to leave you unharmed. . .

A grating sound came from the dragon's throat . . . "You offer me safety! You threaten me! With what?"

"With your name, Yevaud."

Ged's voice shook as he spoke the name, yet he spoke it clear and loud. At the sound of it, the old dragon held still, utterly still.

[Tony Marston]

Well I don't know if your "article" is exactly your application code, but when I look at that code (correct me if I am wrong) from the part2:

        case 'delete': 
            // delete all related rows 
            $where = NULL; 
            foreach ($reldata['fields'] as $one => $many) { 
               $where .= "$many='$fieldarray[$one]' AND "; 
            } // foreach 
            $where = rtrim($where, ' AND'); 
            // set up query to update the database 
            $query = "DELETE FROM {$reldata['many']} WHERE $where"; 
            $result = mysql_query($query, $dbconnect) or trigger_error("SQL", E_USER_ERROR); 
            break; 

I am concluding that you delete all children of a parent and you do so explicitely with an SQL query, you are not talking to the relationship "table object".

You are quite correct. However, in my main application (which is far bigger than the sample application) I have converted the code so that instead of building the SQL query to delete child occurrences within the parent object I actually pass control to the relevant child object to perform the delete. I did this mainly to fit in with my audit logging feature in which I write the details of every deleted record to the audit database.

[Tony Marston]

Reply for your person_name example:

Then if there is anything that is heavy computation, is that done a lazy way? Or each time you do a query?

There is no simple answer to that question as the number of times where a required value does not exist on the database and therefore has to be computed is immeasurable. There are two ways of doing the calculation:

• Within an sql SELECT statement.
• Within PHP code somewhere in the class.

All I have to do is choose which technique I want then put the code in the right place so that it gets executed at the right time. What that code is and where I put it depends entirely on the circumstances of each calculation. I cannot put it any differently than that.

[lastcraft]

Hi...

...but if he makes a statement which is factually incorrect, and I have the audacity to say so, then I am immediately accused of being arrogant.

It wasn't incorrect. Your quote appears to be describing the scope mechanics of the "class" keyword, rather than design decisions, or has simpified things for easier digestion. I cannot tell out of context. If it is stating an absolute design principle then the quoted text is very poor.

If you consider a DataMapper to be breaking encapsulation then your view of it is simplistic. It actually achieves greater encapsulation by making the the data access signatures invisible to the domain. It also moves the creation of the data access classes from the domain to the application code where configuration usually takes place, thus adding a flex point in the place it needs to be. The DataAccessor pattern buries the choice of data access inside the domain objects. If you ever want to change the DB, although you won't usually, then you are in trouble.

The only way to change the choice of database without editing the domain layer (using DataAccessors) would be to have some hidden configuration object working behind the scenes. This would mean that the code that controls this class's behaviour would appear in two separate places, the domain object and the configuration. This means you could secretly change the implicit behaviour (domain) with an external interface (configuration) without going through the explicit interface. This would be "bad" design because it would break encapsulation.

Here is a quote I once heard on the subject...

Encapsulation means that the class must define all the properties and methods which are common to all objects of that class. All those properties and methods must exist inside a single container or 'capsule', and must not be distributed across multiple locations.

(Sorry, that comes across as antagonistic and I really mean it is a joke. The point is that things are more complicated than just having everything hidden behind a single class once you start adding flex points).

yours, Marcus