Data Access Layer - Is there a real seperation?

[MickoZ]

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!)

I have not read it nor am I knowledgeable about know pattern, but I saw in one of your FAQ (The one you talk about FrontController) that you refer to Martin Fowler Book. I don't know if you read it or what. But the Table Data Gateway pattern is described in that book:

http://www.martinfowler.com/eaaCatalog/

[lastcraft]

Hi...

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!)

I am not really a fan of that name either. The names are from "Patterns of Enterprise Application Architecture" by Martin Fowler. You'd like it (honest).

yours, Marcus.

[lazy_yogi]

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!)

No, it's the same book referred to by most sitepoint members. Most everyone here quotes martin fowlers PoEAA book which is where much of the terminology comes from (Table gateway, row gateway, mapper, etc ..). The book is exceptional - IMO the best book i've read on fine grained architecture, but many sitepoint members often regard it as a bible and don't think why they are following it.

I also feel that encapsulation is one of the most imortant rules, and splitting up classes does add a layer of complexity. I don't know if one way is 'better' than the other, but I prefer the simpler method of a single class, and only feel a seperate mapper class is required for very complex systems with a badly designed legacy database design that needs complex mapping between objects and the database.

People that ignore the KISS principle can end up with a horrid system that is horribly difficult to use and maintain. I've seen systems that are worse than proceedural code with globals all of the damn place. And at the end of the day, the point of design and OOP is for easy maintenance.

[dagfinn]

A DataMapper splits persistence off from the domain object leaving both classes more cohesive. The price you pay is extra client code handling two objects. What you gain is divide and conquer on the complexity of the code. Smaller classes are easier to get right. You can also swap them around. You can use the application with different databases just by choosing a different mapper at run time without touching any of the domain object code. This makes it easier to test as well.

Absolutely. And there is one more thing: by separating responsibilities, you are separating parts of the code that are likely to change for different reasons. So there's a greater likelihood that a change will affect fewer classes.

[dagfinn]

And now to really confuse you...the Propel way.

$criteria = new Criteria();
$criteria->add(UserPeer::NAME, "%John%", Criteria::LIKE);
$users = UserPeer::doSelect($criteria);

foreach($users as $user)
{
    echo $user->getId();

    // Propel entity classes can save state so we could do this:
    // $user->setLastName('Smith');
    // $user->save();
} 

or you can write your own method and add it to the generated stub peer class.

$users = UserPeer::findUsersByName("John"); 

Fun eh?

Hoping perhaps to unconfuse someone by relating this to Fowler's terminology: $criteria is a Query Object. $user is a Row Data Gateway or an Active Record, depending on sophistication.

[dagfinn]

According to this OOP Tutorial the term 'encapsulation' is defined as
...
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.

I have to agree with Marcus that this is not a black and white issue. But you have a point, and it's about the relation between a conceptual object and a syntactical one. There are reasons to try to avoid fragmenting a conceptual object too much. I believe this is part of the reason why J2EE has been losing popularity, that it causes just this kind of fragmentation.

But data storage code is not a natural part of a domain object. For example: a product has a price. So the price is an essential aspect of a Product object. On the other hand, how the Product object is stored--in a database, in an XML file, or somewhere else--is not; it's incidental. That's the main reason why Data Mappers are a good idea.

[Tony Marston]

Your quote appears to be describing the scope mechanics of the "class" keyword, rather than design decisions, or has simpified things for easier digestion.

If I have an entity called Customer then I will put all information, properties and methods, for that entity in a single class. This is what encapsulation is all about. I do not see the point of breaking that up into smaller classes, each containing a subset of information. If I wish to do something with a Customer then I have a single point of the reference, the Customer class.

If you consider a DataMapper to be breaking encapsulation then your view of it is simplistic.

That is because I believe in the KISS principle. I do not like to make anything more complicated that it needs to be.

If you ever want to change the DB, although you won't usually, then you are in trouble.

Then you clearly have not understood my design. I have a separate class for each entity which contains the structure of the associated database table. None of these classes communicates with the database directly, this is all done through a separate data access object. Note that I do not have a separate DAO for each database table, I have a single DAO for the entire application. When the business object wishes to communiucate with the database, such as adding or updating a record, it passes two pieces of information to the DAO - an array of data, and the table structure. It is up to the DAO to then construct the relevant query string then call the API for that database. Also note that I have a separate version of the DAO for each different database engine, so if I ever want to change databases all I have to do is instantiate my DAO from a different class.

Note that the move to MySQL version 4.1 and above is the same as switching databases as the database APIs are different.

The point is that things are more complicated than just having everything hidden behind a single class once you start adding flex points.

A 'flex point' sounds like a 'point of complexity', so according to the KISS principle it must be a 'bad thing'.

[Tony Marston]

I have not read it nor am I knowledgeable about know pattern, but I saw in one of your FAQ (The one you talk about FrontController) that you refer to Martin Fowler Book. I don't know if you read it or what. But the Table Data Gateway pattern is described in that book.

I have not read the Martin Fowler book, nor do I intend to. I already have two books on design patterns, and that is more than enough. I wrote that FAQ on the Front controller in respnse to an 'expert' who said:

Everybody else uses a front controller, so they must be a 'good thing'. Why don't you?

[Tony Marston]

People that ignore the KISS principle can end up with a horrid system that is horribly difficult to use and maintain. I've seen systems that are worse than procedural code with globals all of the damn place. And at the end of the day, the point of design and OOP is for easy maintenance.

I have seen this happen in real life, so I know that it's true. I once worked on a project where a team of 'experts' spent 3 man-years building an infrastructure based on the 3-Tier architecture. When they finished it and tried to build 2 simple transactions it took them another 2 weeks. I thought this was crap, and told them so. The client also thought it was crap as he cancelled the project.
By following the KISS principle I took my own 2-Tier development environment and converted it to 3-Tier, then built a family of 6 transctions instead of their 2. How long did it take me, with my outdated methods and simplistic approach? Just 2 weeks. So what those 'experts' failed to achieve in 3 man-years I polishd off in 2 man-weeks. That is why I have a low opinion of so many 'experts'. They can talk the talk, but they cannot walk the walk.

[Tony Marston]

And there is one more thing: by separating responsibilities, you are separating parts of the code that are likely to change for different reasons. So there's a greater likelihood that a change will affect fewer classes.

But in order to have the ability to change fewer classes I must double the number of classes? That does not sound kosher to me.

[Tony Marston]

But data storage code is not a natural part of a domain object. For example: a product has a price. So the price is an essential aspect of a Product object. On the other hand, how the Product object is stored--in a database, in an XML file, or somewhere else--is not; it's incidental. That's the main reason why Data Mappers are a good idea.

I do not have domain objects, I have objects which exist in either the presentation, business or data access layers.

I do not have data storage code in any business object. I have a separate data access object which constructs all sql queries and calls the relevant database API. All I have in each business object is an array of column names, and this array is passed to the DAO for processing. The business object does not know how the DAO deals with each query, just that it does. Isn't that how it's supposed to work?

[Version0-00e]

Hmm, seems like people are getting in flame mode here. Lets try to keep it nice

Yer, is starting to get a bit close to that sort of thing

I'll just be off then, before it goes nuclear

[kuato]

Hoping perhaps to unconfuse someone by relating this to Fowler's terminology: $criteria is a Query Object. $user is a Row Data Gateway or an Active Record, depending on sophistication.

In that example I gave of Propel a $user is a Row Data Gateway that implements the Persistent interface(save, delete, etc) and a UserPeer is a Table Data Gateway which is used for querying to create one or more users. Peer methods can be customized via the stubs and utilize Criteria objects or avoid them for specialized queries. Sorry for leaving that out doh. I mentioned that in another post somewhere but not in this one.

[lastcraft]

Hi...

If I have an entity called Customer then I will put all information, properties and methods, for that entity in a single class. This is what encapsulation is all about. I do not see the point of breaking that up into smaller classes, each containing a subset of information.

This is so idiotic it doesn't even stand on it's own terms. If a Customer has an employer then I have to make all messages to the Employer class go through the Customer? If I write code to bulk mail my customers I have to pass in the whole Customer class rather than just a Contact object. That's your idea of encapsulation?

Have I walked into some kind of Turing test?

That is because I believe in the KISS principle. I do not like to make anything more complicated that it needs to be.

The code for DataAccessor and DataMapper is about the same. Simplistic is not Simple, Simplistic is blinkered.

Then you clearly have not understood my design.

I am not the slightest bit interested in your design and haven't looked at it. I am simply responding to your comments so far. I also feel a duty to defend the community spirit in this group, otherwise I wouldn't even respond. Really your posts barely belong in the advanced forum.

...so if I ever want to change databases all I have to do is instantiate my DAO from a different class.

If switching DB is a possibility then you have added a flex point. You have done it in a way that breaks encapsulation (as I explained before). A DataMapper would probably be a cleaner solution given that requirement. From what you have just said though, it sounds like your system is nearer to client-server rather than a domain driven system in any case.

A 'flex point' sounds like a 'point of complexity', so according to the KISS principle it must be a 'bad thing'.

Flex points are requirements from the application in engineering form. If you don't have any (or are ignorant of them) then you cannot write an OO application that does any more than a bunch of procedural scripts could.

WidowMaker (we know who you are ) mentioned going Nuclear...

You are fond of emphatic statements, presumeably to sound authoritive, so at the risk of being bounced by the moderators I'll make one. You're bullying tactics may work on the much broader Usenet groups, but Sitepoint is different. I know of no member of this forum that is not willing to learn and the majority (like myself I hope) are doing their best on that journey. As a result there is a rare degree of skill and understanding here and no one gets an easy ride. You expect people to painstakingly read your first attempts at OO design when you yourself cannot even be bothered to read the standard texts? You claim you are not arrogant?

It's like some local thug suddenly gaining entry to criminal gang and finding themself out of their depth. You bravado just sounds shrill and desperate.

yours, Marcus

[Version0-00e]

You are fond of emphatic statements, presumeably to sound authoritive, so at the risk of being bounced by the moderators I'll make one. You're bullying tactics may work on the much broader Usenet groups, but Sitepoint is different. I know of no member of this forum that is not willing to learn and the majority (like myself I hope) are doing their best on that journey. As a result there is a rare degree of skill and understanding here and no one gets an easy ride. You expect people to painstakingly read your first attempts at OO design when you yourself cannot even be bothered to read the standard texts? You claim you are not arrogant?

It's like some local thug suddenly gaining entry to criminal gang and finding themself out of their depth. You bravado just sounds shrill and desperate.

And who is that aimed at? Me?

[lastcraft]

Hi...

And who is that aimed at? Me?

No, certainly not! Sorry, you got hit by shrapnel .

yours, Marcus

p.s. I was going to report my own post to the moderators, but it seems you can't. Funny old world...

[kuato]

Marcus,

You've always been one to keep your calm and are right up there with Harry and Voostind(we miss you Voos!) for being the most respected members of the PHP community.

However, I can't blame you one bit for getting a bit nasty toward Tony and it was actually quite fun seeing that side of you

You are fond of emphatic statements, presumeably to sound authoritive, so at the risk of being bounced by the moderators I'll make one. You're bullying tactics may work on the much broader Usenet groups, but Sitepoint is different. I know of no member of this forum that is not willing to learn and the majority (like myself I hope) are doing their best on that journey
yours, Marcus

Here here. I went through a horrible stage of trying to grasp MVC and applying Fowler's design patterns. To make matters worse I was trying to fit all that into a system that was mostly procedural and chock full of globals when I was making a portal for phpbb2. It ended up being a total mess but I learned a lot in the process from reading your posts and many others here on this forum.

I've now dumped that portal project and have started fresh focusing only on PHP5 and having a blast writing code that works within the Mojavi3 framework(kudos to Sean for such an excellent framework).

[MickoZ]

I like to be analytical and that with people comportement also. I must admit and if you analyse people, that if someone talk differently or is direct in his thought, the mass often react in a bad way (like Tony is doing). I doubt Tony has bad intention but he is also doing assumption like other are doing.

Probably all we are discussing here are very similar, but just implemented a different way.

An attitude might make you mad (like Tony's one) but you may want to go beyond apparence.

Tony is probably documenting his stuff because he is proud of his solution (bragness which is nothing bad IMHO) and of course also because he wish to educate people or help people learn. That is also probably the reason he is replying to all those post. Same with lastcraft, etc. ;-) I guess for some little word or a more direct tone, people get a bit nervous/annoyed. I would suggest to not worry much about this. It is often just a tone, a way to act. Actually Tony's writting has a direct tone with some arroangace we could probably say (I would classify this in a kind of humour).

lastcraft, you might want to read and just look at the tony's way to do thing, it is an interesting thing and then you can see if it is what you think or not (you claim you haven't done it, but maybe you took a look... however, it is better to check it).

I guess we can all be direct, criticize (an hypothetically way) and give our opinion. That way we can all evolve well (Tony included!). He has never said his way was the only way or what, but from his claim, his way seem efficient and productive and is probably very similar to some pattern. It is maybe just not separated as much as some would want to do.

Actually by looking fast at his stuff, there would probably be an easy way to add a user domain class (i.e. User); rename his actual User class to something like UserTableHandler (sorry don't go ahead and criticize the name) and in User provide method so it can go to an array so it can be used like an object: User->properties, etc. But then Tony would probably say that it is adding one level of complexity to much because apparently his way support all he need. ;-)

[lastcraft]

Hi...

I am about to add "off topic" to my sins. Oh well...

lastcraft, you might want to read and just look at the tony's way to do thing, it is an interesting thing and then you can see if it is what you think or not (you claim you haven't done it, but maybe you took a look... however, it is better to check it).

I would love to read every bit of code that came my way. The brutal truth is that I don't have time. Mr Marstons creation has to compete with likes of Seagull, WACT and Mojavi (which I am looking at now) just in the PHP arena alone. Sorry, but I have to be selective. I don't choose by the "directness" of the author, but from what I know of the knowledge, skill and care they are likely to put into their project.

Now I will make exceptions to people who ask me nicely for a design or code review. I may make some good suggestions, or just bad ones, or mad ones. Whatever happens there is the chance that the discussion will spark off something interesting. Even if it doesn't I may have helped someone in the same way I get help. Without people contributing their time then you don't have a community. If people won't listen then people won't contribute.

And this community is exceptional.

Several projects have been spawned from this forum because of the freedom to discuss half formed ideas in an open way. You only have to look at the progression of MVC debates, and now persistence, to see that happening. I haven't seen much of that on this thread. I have seen lot's of misleading advice. Qualifying just one piece of this bogus advice has been like banging my head on a wall.

Rudeness and stubborness are not characteristics we can live with, they are extremely damaging in a forum. They intimidate those who might challenge. In so doing they leave a trail of poor quality information (dismal in this case). I have obviously tarnished my own reputation in this exchange, but I feel something has to be said. I'll try to be polite (I fail often), but I am not a pacifist.

Sorry, but I don't tolerate rudeness or intimidation here or anywhere else.

yours, Marcus

[MickoZ]

Offtopic too (but I believe a topic can sometime need other kind of interaction... )

Yeah, some people bash too fast. Personally I believe discussion should be done in a honnest way. You don't agree or don't understand or what, said it. Of course Tony's tone sound attacking for a lot of people, I don't know what his intention is.

I will have to take a peek at the thread of MVC and Data Persistance mainly.

I sometime find myself reading too much thread, article, etc. I of course more I evolve think to do bigger stuff, cleaner, more flexible, etc.

I think my major problem is the lack to FOCUS. I guess you have a good reputation in OO related topic, would you have a good roadmap to begin to be "better". I know/understand OOP at basic (at less I think I do ), have saw that at school often and was not bad in it (being modest ). But I mean going further in OOP, not learning useless stuff but getting to understand better architecture, maybe the pattern stuff (often I check at pattern and they seem to be similar to "idea" I got... I guess that is why we call them a pattern).

Well my question is this: what you suggest as reference/roadmap if you can suggest that?

I believe school is efficient often for me because it gives me a roadmap. I don't need to listen to all what teacher say or what, but the class give me a checklist of thing I need to learn. example:

1. OOP Basic
--> go there or read that
2. You should then learn X (Pattern)
good link:
good book:
3. You should read those book:
martin fowler - POEEA
4. ...

etc.

I am looking for something clear, reasonable, etc. Probably the bluechip, the best thing to go on. If I need to lead someone to learning PHP let's say, I can give him some directive, lecture so he learn it very good in 2-3 days let's say (if not less). Of course when it comes to architecture there is a lot of more thought and possibility to do (or advanced php programming), but usually the concept can always be mastered a "simple way" (what is simple is good, it is sometime hard to make something simple, but once it is simple it rocks.)

Well if you can give me suggestion, I would appreciate

[Tony Marston]

If I have an entity called Customer then I will put all information, properties and methods, for that entity in a single class. This is what encapsulation is all about. I do not see the point of breaking that up into smaller classes, each containing a subset of information.

This is so idiotic it doesn't even stand on it's own terms. If a Customer has an employer then I have to make all messages to the Employer class go through the Customer? If I write code to bulk mail my customers I have to pass in the whole Customer class rather than just a Contact object. That's your idea of encapsulation?

I am not confusing the issue with subclasses. I am merely saying that I have a single User class, not a User and a UserMapper class.

The code for DataAccessor and DataMapper is about the same. Simplistic is not Simple, Simplistic is blinkered.

If the code is the same then why have two classes?

Then you clearly have not understood my design.

I am not the slightest bit interested in your design and haven't looked at it. I am simply responding to your comments so far. I also feel a duty to defend the community spirit in this group, otherwise I wouldn't even respond. Really your posts barely belong in the advanced forum.

You are arguning just because I dare to disagree with you. Just because I choose to read from a diffent design 'bible' you seem to think I am a heretic. I do not have DataAccessor or DataMapper classes for the simple reason that I do not follow that particular design methodology. I use the 3 tier architecture in which I have components in the presentation layer, the business layer, and the data access layer.

...so if I ever want to change databases all I have to do is instantiate my DAO from a different class.

If switching DB is a possibility then you have added a flex point. You have done it in a way that breaks encapsulation (as I explained before). A DataMapper would probably be a cleaner solution given that requirement. From what you have just said though, it sounds like your system is nearer to client-server rather than a domain driven system in any case.

I do not have 'flex points'. I have business logic in the business layer and data access logic in the data access layer. The purpose of a data access layer is so that I can switch databases whenever I wish. My code fulfills that purpose, therefore it cannot be wrong.

How can having a data access object possibly break encapsulation?

You should also be aware that switching from MySQL version <=4.0 to version >=4.1 requires the usage of a completely different set of APIs, so it is very similar to switching from one DBMS engine to another. Therefore I have one DAO class which uses the mysql_* functions, and another which uses the mysqli_* functions, so I can easily make the switch from one to the other.

Flex points are requirements from the application in engineering form. If you don't have any (or are ignorant of them) then you cannot write an OO application that does any more than a bunch of procedural scripts could.

Flex points do not appear in any of the design philosophies which I read, therefore I do not consider them to be a 'requirement'. I have written code which demonstrates the use of encapsulation, inheritance and polymorhism, and as these are the primary principles of OOP my code is therefore OO. It may not be your particular brand of OO, but that is irrelevant (IMHO).

[DougBTX]

I do not have 'flex points'. I have business logic in the business layer and data access logic in the data access layer. The purpose of a data access layer is so that I can switch databases whenever I wish.

Using layers makes your code more flexible, so the points where those layers meet are called "flex points". (Easy )

Douglas

[MickoZ]

If the code is the same then why have two classes?

Common Tony... The code is not always the same. The reason to have two classes is to separate two different topic even thought they can be linked to one topic. It is separation and we can separate something indefinitely (I EXAGERATE THERE OF COURSE!).

But you probably done project management or writting stuff.

You can put 10 topics separated with header in one document. You can make 10 documents. You can make 3 classes, you can make 1. But in a design/analysis context the X concepts are still there.

If you write 1 document divised in 10 sections, or 10 documents (covering 1 section/topic each) you still have 10 section aren't you? ;-)

It is easy to think that analyticelly an User has some property, message, etc. in OOP. And that the action to persist is something else. You can bind everything, there is relation, but you can also separate some part, usually we do this with major part.

It is like in your validation routine (in your example).

You can do

function validate ()
{
  if type == x
  { ... code
  }
  else if type == y
  {
    ... code
  }
  else ...
}

you can also do

function validate ()
{
  if type == x
  {
    validate_x(...);
  }
  else ...
}

Why code another function and why not? Sometime it is a matter of taste, sometime it is a matter of separate thing. Both are ok, it all depends of the need, etc. But that you do another function, or not, you still have that concept of validate_type_x...

You probably know and understand all this ;-)

[Tony Marston]

I am looking for something clear, reasonable, etc. Probably the bluechip, the best thing to go on. If I need to lead someone to learning PHP let's say, I can give him some directive, lecture so he learn it very good in 2-3 days let's say (if not less). Of course when it comes to architecture there is a lot of more thought and possibility to do (or advanced php programming), but usually the concept can always be mastered a "simple way" (what is simple is good, it is sometime hard to make something simple, but once it is simple it rocks.)

Well if you can give me suggestion, I would appreciate

In my experience there are only two ways of learning:

• Teach youself.
• Be taught by someone else.

Teaching yourself involves reading books and articles, dissecting other people's code to see how it works and how it is put together, then trying your own code to see if it works.

Having a teacher means having someone who can give you the benefit of his experience, can suggest better ways of designing or coding, and can spot when you are going down the wrong path and put you on the right one.

The best way is a combination of both. But beware! Just as there are books and articles out there which preach some questionable theories, there are also some people out there whose ability to misinterpret and misapply those theories (questionable or not) just boggles the mind!

I have read many books, both good and bad, and been taught by many people, both good and bad, so how do I tell the difference between good and bad? I use the old technique known as 'suck it and see!'. I try it, and if it works I use it, and if it doesn't I loose it. At the end of the day the only REAL thing that matters is that you produce code which works AND which can be understood and maintained by others. This is VITALLY important if you are working as part of a team.

As for all those design patterns, levels of abstraction, classes for this and classes for that - they are all different depending on which 'bible' you read and follow. I do not follow any particular 'bible' with religeous ferver, therefore I am treated by some (no names, no pack drill!) as a heretic. If I follow any religion at all then I must be a devout pragmatist. Dogmatism just isn't my scene, man.

There is no 'one way', no 'true way' to design and write code. There are as many different ways as there are grains of sand in the desert. It is simply a matter of sifting through all those possibilities until you find something that makes sense and that you can make use of. Happy hunting!

[MickoZ]

Well Tony, I won't buy all pattern and stuff. But having thinking of some design and looked fast fast at some of the pattern, some of them look like idea I have (not all of course), so I want to see what is the supposed clean way people have used for them ;-)

There is book that might waste your time and not other, but there is book that are really good and most people can read and get a good understand of something. A book has the advantage to be structured, etc. Like a class, or a roadmap.

Of course you try to avoid the so-called expert because your experience has been bad or what. Standard is GOOD and BAD and all smart people know this. I guess most thing have a good and bad side.

If they are called pattern, it is either that they fit to fix some common problem (pattern to do something) or that people often do it that way (a pattern way). They might just inspirate us and it is nothing (and I doubt people do that 100%) to follow 100% to the letter. But if you take something like Singleton, it is useful, it is simple, it is a clean way to do it. You may or not have read about those DataMapper/ActiveRecord/Etc. However, they might also give you a clean way to do stuff. Some of the stuff are quite intuitive, some less. Blah blah.