SitePoint Sponsor

User Tag List

Page 3 of 5 FirstFirst 12345 LastLast
Results 51 to 75 of 110
  1. #51
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by otnemem
    Q. Do you declare these parts of the SQL in your view? I mean, the $where part that you pass down to the data access layer.
    The contents of the $where variable come from user input. For example, I have a search screen which shows the user a set of empty fields where he/she can enter search criteria, with or without wildcard characters. When the SUBMIT button is pressed the search script will take the contents of the $_POST array, assemble a suitable WHERE clause, write it it to the $_SESSION array, then jump back to the calling form, which will usually have a screen with multiple occurrences. When this "list" screen is activated the page controller will extract the $where details from the $_SESSION array, then pass then to the relevant business object as the parameter on the getData($where) method.

    Within the list screen it is possible to mark any number of displayed rows as "selected" using a checkbox at the start of each row. When one of the navigation buttons is pressed the list component will take the primary key of each of the selected rows and construct a suitable WHERE string, write it to the $_SESSION array, then jump to the component identified by that particular navigation button. That new component will do whatever is necessary using the $where string passed to it.

    A simple mechanism, but it works very well.

  2. #52
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay Helge

  3. #53
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bdunlap


    I'm new to posting on these forums, but have lurked here for quite some time and am very familiar with your act. You have the uncanny ability to bring down the quality of an entire forum thread with this type of garbage (not to mention the shameless, non-stop pimping of your website).

    Consider yourself reported.
    Oh no! I've been reported to the paradigm police! AGAIN!! Oh, the shame! Oh, the ignominy!

    HA! Ask me if I care.

  4. #54
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's no laughing matter I suppose? We are here for the enjoyment of learning and helping other members, it's just now and again things get silly

    Today just seams to be one of those days I suppose...

  5. #55
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Quote Originally Posted by Tony Marston
    None of my objects has knowledge of the layer above it.
    I'd beg to differ; You have SQL within the Presentation layer which actually in fact belongs within the Model layer to my mind of understand MVC - or nTier for that matter
    Since when does "having sql fragments in my presentation layer" become the same as "one layer having knowledge of the layer above it"? I do not see the connection. I do not understand your logic.

    Quote Originally Posted by Dr Livingston
    Also I might add that I personally am not arrogant; I read the posts on these forums and I actually learn from them. I like to think that folks are helping me out, and I am indeed trying to help you out as well but you are ignoring the advice.
    There is a big difference between giving me advice and telling that I am out-and-out wrong, then calling ME arrogant because I refuse to admit that I am wrong. My methods cannot wrong for the simple reason that they work. They may be different to your methods, but that does not make them wrong.

    My methods are different because
    • I may be working from a different set of rules.
    • I apply a different interpretation as to what those rules actually mean.


    Quote Originally Posted by Dr Livingston
    If my advice is wrong, then sure enough someone will point that out, and again I'll take note of my error, but I think your layering is wrong, and a few other members think your layering is wrong as well, so surely we cannot all be wrong huh?
    You think that my layering is wrong. Fine. I just happen to disagree with your argument as to why exactly it is wrong. My implementation of the 3-tier architecture conforms to the pattern I first came across years ago. It does not contain these "rules" that you keep throwing in my face, so I do not see any need to follow them.

    Quote Originally Posted by Dr Livingston
    Are you going to be arrogant enough to say we are eh? Your SQL is in the wrong place for the love of God, like how many different ways can we put that to you? Doesn't matter is it's fragments of SQL or whatever, it's still in the wrong place.
    Can you show me any definition of the 3-tier architecture that says any such thing? The only definitions I have seen simply identify what the 3 tiers are and what they do. HOW they do it is irrelevant. I can put whatever sql fragments I like in whatever layer I like, but it is only the data access layer that is allowed to assemble these fragments into a complete query and execute it. THAT rule I follow.

    Quote Originally Posted by Dr Livingston
    For the Martin Fowler quote, that is something I'm not familuar with; maybe you can post the url where the quote is
    Apparently it is a quote from his book, not from any web page. It was posted in another thread some time ago by someone who was helping me defend my point of view.

    Quote Originally Posted by Dr Livingston
    Yer, I'm kind of finding it extremely difficult to find any sense in replying to Tony's posts as well now, the lad just doesn't listen; It's like he knows everything there is to know, and personally I cannot be doing with people who are ba' heeded
    I listen to what you have to say, but your interpretation of the "rules" is so far off course (compared with my own interpretation) that I just cannot take them seriously.

    You, and others like you, just cannot accept the fact that my methods are different, yet they still work. Following an arbitrary set of artificial rules is not the name of the game - producing workable software is.

  6. #56
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Tony,

    I dont know how this thread turned into a thread about your infrastructure but it has so Ill do my best to explain why people are saying that your infrastructure breaks layering and how a datasource layer helps.

    The code below has no data source layer. Its our basic procedural php.
    PHP Code:
    // Find All With Lastname Like
    $sql 'SELECT * ' .
           
    'FROM CUSTOMER ' .
           
    'WHERE CUSTOMER.LASTNAME LIKE ' .
    mysql_escape_string($_GET['lastname']);
    $result mysql_query($sql);
    while (
    $customer mysql_fetch_assoc($result)) {
        
    $customers[] = new Customer($customer);
    }

    // Find All With Lastname Like
    // Only Firstname Lastname
    $sql 'SELECT FISTNAME, LASTNAME ' .
           
    'FROM CUSTOMER ' .
           
    'WHERE CUSTOMER.LASTNAME LIKE ' .
    mysql_escape_string($_GET['lastname']);
    $result mysql_query($sql);
    while (
    $customer mysql_fetch_assoc($result)) {
        
    $customers[] = new Customer($customer);

    Now lets take a look at how we would do this with your infrastructure:
    PHP Code:
    // Find All With Lastname Like
    $customer = new Customer();
    $where 'CUSTOMER.LASTNAME LIKE ' .
             
    mysql_escape_string($_GET['lastname']);
    $result $customer->getData($where);

    // Find All With Lastname Like
    // Only Firstname Lastname
    $customer = new Customer();
    $customer->sql_select  'FISTNAME, LASTNAME';
    $where 'CUSTOMER.LASTNAME LIKE ' .
             
    mysql_escape_string($_GET['lastname']);
    $result $customer->getData($where); 
    The problems here are that, the fact you are using a relational database is known, your database schema is known, you couldnt substitute an alternative layer for a different datasource. (etc. as has already been explained)

    Using your infrastructure, we can make a datasource layer like below:
    PHP Code:
    $customerDS = new CustomerDataSource();
    // Find All With Lastname Like
    $result $customerDS->findAllWithLastnameLike($_GET['lastname']);

    // Find All With Lastname Like
    // Only Firstname Lastname
    $result $customerDS->findAllWithLastnameLikeOnlyLastFirst($_GET['lastname']);

    class 
    CustomerDataSource {
        function 
    findAllWithLastnameLike($lastname) {
            
    $customer = new Customer();
            
    $where $this->getWithLastnameLikeWhereClause($lastname);
            return 
    $customer->getData($where);
        }
        function 
    findAllWithLastnameLikeOnlyLastFirst($lastname) {
            
    $customer = new Customer();
            
    $customer->sql_select  'FISTNAME, LASTNAME';
            
    $where $this->getWithLastnameLikeWhereClause($lastname);
            return 
    $customer->getData($where);
        }
        private function 
    getWithLastnameLikeWhereClause($lastname) {
            return 
    'CUSTOMER.LASTNAME LIKE ' .
                   
    mysql_escape_string($_GET['lastname']);
        }

    Granted, you've already encapsulated certain parts of the datasource layer, you just didnt finsish the job IMO.

    The advantages of this are:
    All the code that has to do with, the fact we have a relational database and the databse schema are in one class. They arent scattered around different controllers.

    If we wanted to change the schema so that the LASTNAME column was split into a LASTNAME and MIDDLENAME column we have a single class to make changes to it.

    If we wanted to store our customers in a csv file instead of the database we could do that easily by making changes to a single class instead of every controller that used the customer object.

    We simply change the CustomerDataSource class to this:
    PHP Code:
    class CustomerDataSource {
        function 
    findAllWithLastnameLike($lastname) {
            
    $handle fopen("customers.csv""r");
            while ((
    $row fgetcsv($handle1000",")) !== FALSE) {
                if (
    $this->isLastnameLike($lastname$row[1])) {
                    
    $customers[] = $this->loadCustomer($row);
                }
            }
            
    fclose($handle);
            return 
    $customers;
        }
        function 
    loadCustomer($row) {
            
    $customer = new Customer();
            
    $customer->setFirstname($row[0]);
            
    $customer->setLastname($row[1]);
            
    $customer->setDOB($row[2]);
            return 
    $customer;
        }
        function 
    findAllWithLastnameLikeOnlyLastFirst($lastname) {
            return 
    $this->findAllWithLastnameLike($lastname);
        }

    You may never need to do this, but I have, and had I used youre infrastructure I wouldnt have been able to do that without major work which didnt need to be done had I layered properly.

    Quote Originally Posted by Tony Marston
    Apparently it is a quote from his book, not from any web page. It was posted in another thread some time ago by someone who was helping me defend my point of view.
    PoEAA, top of page 18.
    Last edited by Brenden Vickery; Jan 25, 2005 at 14:57.

  7. #57
    SitePoint Enthusiast mjlivelyjr's Avatar
    Join Date
    Dec 2003
    Location
    Post Falls, ID, US
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston
    Since when does "having sql fragments in my presentation layer" become the same as "one layer having knowledge of the layer above it"? I do not see the connection. I do not understand your logic.
    By having any SQL fragements in your presentation layer creates a dependancy within your presentation on SQL. For example, if the database gods decided one day to radically alter SQL then you would have to make changes to your presentation layer because it has that dependency (or knowledge if you will) of SQL. SQL is obviously something that should be in the Data Access (Infrastructure) layer and if we are talking a 3 tiered application the presentation layer should have absolutely no dependancy on your data access layer.


    Quote Originally Posted by Tony Marston
    There is a big difference between giving me advice and telling that I am out-and-out wrong, then calling ME arrogant because I refuse to admit that I am wrong. My methods cannot wrong for the simple reason that they work. They may be different to your methods, but that does not make them wrong.
    I have not read through this entire thread and I don't particularly care to take the time too, but I would wager to guess people aren't telling you that you are wrong because they don't think your methods work. They are telling you wrong because you claim your method adheres to a certain design principle that it does not. So it's not so much your method that's wrong as it is your defense of your method is wrong. Also, just because something works doesn't mean it's the best solution for a problem. Hence the term "best practices."

    Quote Originally Posted by Tony Marston
    My methods are different because

    * I may be working from a different set of rules.
    * I apply a different interpretation as to what those rules actually mean.
    My word...if anybody can apply whatever interpretation they want to any principle of programming then why on earth did I bother to go to school.




    Quote Originally Posted by Tony Marston
    You think that my layering is wrong. Fine. I just happen to disagree with your argument as to why exactly it is wrong. My implementation of the 3-tier architecture conforms to the pattern I first came across years ago. It does not contain these "rules" that you keep throwing in my face, so I do not see any need to follow them.
    Perhaps you can provide us with a direct link to a description of this pattern you came accross.



    Quote Originally Posted by Tony Marston
    Can you show me any definition of the 3-tier architecture that says any such thing? The only definitions I have seen simply identify what the 3 tiers are and what they do. HOW they do it is irrelevant. I can put whatever sql fragments I like in whatever layer I like, but it is only the data access layer that is allowed to assemble these fragments into a complete query and execute it. THAT rule I follow.
    Well, lucky for you I just spent the first hour or so of my day buried in my PoEAA book (I recommend you get it.) Here are some quotes for you. I am getting all of these out of the 1st chapter:

    You can understand a single layer as a coherent whole without knowing much about the other layers. You can understand how to build an FTP service on top of TCP without knowing the details of how ethernet works.
    Your presentation layer, by using SQL, requires you to have knowledge of how SQL works.

    You minimize dependencies between layers. If the cable company changes its physical transmission system, providing they make IP work, we don't have to alter our FTP service.
    Like I said before, if for some reason users of your code changed DMBS and the system didn't have the same support for SQL as your current DBMS code would not only have to be changed in your data access layer but also in your presentation layer because you are including SQL in that layer.

    For your viewing pleasure here are some more articles that give a definition contrary to what you are saying:

    http://www.jguru.com/faq/view.jsp?EID=125072
    http://en.wikipedia.org/wiki/Three-tier_(computing)
    http://www.phppatterns.com/index.php...leview/18/1/1/

    if you want more just let me know...




    [quote=Tony Marston]Apparently it is a quote from his book, not from any web page. It was posted in another thread some time ago by someone who was helping me defend my point of view.[/qoute]

    Tell me what section of his book the quote comes from and I'll be willing to attempt to back up your usage of it unless you used it out of context.

    Quote Originally Posted by Tony Marston
    I listen to what you have to say, but your interpretation of the "rules" is so far off course (compared with my own interpretation) that I just cannot take them seriously.
    Oh sorry, I didn't realize your interpretation was the one to live by. How many books have you written again?

    Quote Originally Posted by Tony Marston
    You, and others like you, just cannot accept the fact that my methods are different, yet they still work. Following an arbitrary set of artificial rules is not the name of the game - producing workable software is.
    If your methods work and you choose to use them then more power to you. I am perfectly fine that your methods are different. What I do not like is you claim your methods accomplish something that they do not and that is loose coupling of layers and objects. Like I said before, just because something works and it may be really easy to implement doesn't mean it's the best solution to any given problem. If that were the case we would all be living in tents and computers would have never been invented.
    Mike Lively
    Digital Sandwich - MMM MMM Good

  8. #58
    SitePoint Zealot
    Join Date
    Jun 2004
    Location
    Bogota
    Posts
    101
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi Tony,

    As it has been pointed out, having a fraction of a SQL statement on your controller is going to give you the same layering problems as having the complete statement there.

    I think that if you wrap those portions of sql into a finder method in your data access layer you'd get a clearer separations of layers. If you think having a method for each filter is too much, you can have a generic query builder that map your filters to SQL sentences.

    BTW, don't take this as a rule -- I don't.

    Regards,
    - Andres
    If I have wings, why am I walking?

  9. #59
    SitePoint Enthusiast mjlivelyjr's Avatar
    Join Date
    Dec 2003
    Location
    Post Falls, ID, US
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I actually went ahead and found your martin fowler quote for myself. This quote is completely taken out of context. Just to save some backtracking time I'll repost it: (It's from the first chapter of PoEAA for those that want to see it.)

    Layers encapsulate some, but not all, things well. As a result you sometimes get cascading changes. The classic example of this in a layered enterprise application is adding a field that needs to display on the UI, must be in the database, and thus must be added to every layer in between.
    This in no way says anything about whether it's right or wrong to give layers completely open knowledge of eachother. All it is saying is that there are times when changes to your code can cause a ripple effect.

    Say we have a simple Contact Management System that stores Names and E-Mail addresses. If we want to enable the system to manage Phone numbers the change necessary to do so will ripple through all layers of your system. You'll have to add a 'phone' column to a database table, create the ability to deal with phone numbers in your domain layer and then finally modify the presentation layer to show and recieve phone numbers to and from the user. Using column names in your presentation layer isn't in and of itself the problem. Many times the database column name will be the same as the name of the property in the domain layer and the accessor to the domain property will also likely use the same name with a 'get' added to the front of it. The reason why your example breaks layering is because it references the column name <b>as a column name</b>.

    To be perfectly honest with you sometimes you can get by just fine with this method of doing things. I don't (and many others have already and will continue to agree with me) think this is necessarily the best way to do things.

    You aren't that far however from a widely accepted and widely used pattern. Look up Query Object in PoEAA. It can be found in chapter 13. Your idea is almost there. The big difference (and it's the difference really that has caused most of the argument) is that instead of hard coding the column names and what not these are pulled from metadata from the database via Metadata Mapping (also can be found in PoEAA.) In fact I am going to grab a direct quote out of chapter 3 in the section titled Using Metadata.

    When you use Metadata Mapping (306) you have the necessary foundation to build queries in terms of in-memory objects. A Query Object (316) allows you to build your queries in terms of in-memory objects and data in such a way that developers don't need to know either SQL or the details of the relational schema. The Query Object (316) can then use the Metadata Mapping (306) to translate expressions based on object fields into the appropriate SQL.
    So you really aren't that far off from a design that most everyone wouldn't argue against.
    Mike Lively
    Digital Sandwich - MMM MMM Good

  10. #60
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Brenden Vickery
    Ill do my best to explain why people are saying that your infrastructure breaks layering and how a datasource layer helps.
    (....snip...)
    If we wanted to store our customers in a csv file instead of the database we could do that easily by making changes to a single class instead of every controller that used the customer object.
    (...snip...)
    You may never need to do this, but I have, and had I used youre infrastructure I wouldnt have been able to do that without major work which didnt need to be done had I layered properly.
    Thanks, Brenden, for probably the best practical illustration of this problem I've seen in this forum (or anywhere else). Many people have referred to the swapping of one kind of data accessing class for another, but I don't recall seeing an illlustration like this before.

    Tony may correct me if I'm wrong, but I get the impression that he develops alone. Since no one else has to maintain his code and since he evidently has a very good conception of the way his <flamebait>layers</layers> interact, this probably doesn't matter. Contrast his situation with that of lastcraft's (and a few others her as well), who work with other developers or pick up other developers' projects that need refactoring. I'm sure this has a lot to do with the different positions people have taken in this thread and a previous one (which got quite nasty).
    Zealotry is contingent upon 100 posts and addiction 200?

  11. #61
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's it in a nutshell, I think. Most people see peer review as valuable feedback and have the good grace to accept valid criticisms. Failure to do so is very harmful to forums such as this, creating a lot of irritation and bad feeling. Lacking intelligent arguments, all that's left are stubborn, increasingly strident assertions: "I am right and you are all wrong!"

    Personally, I see this as a form of trolling.

  12. #62
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    First I would like to point out that this thread was bloody brilliant until I left it!

    I don't agree much with Tony's design ideas, but reading back over this thread he was neither the rudest nor the most opinionated. Sadly, the best argument against his design is that it would make it harder to do things that you would probably never do (e.g. convert you database to a CSV file). Increasing coupling to simplfy code is a valid design decision. If you can manage the negative aspects of that decision, more power to you.

    We all know that threads deteroriate when the converstation is about who knows "the best way to do things" rather than presenting alternate approaches and letting people choose the one that works for them.

  13. #63
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Brenden Vickery
    Tony,

    I dont know how this thread turned into a thread about your infrastructure but it has so Ill do my best to explain why people are saying that your infrastructure breaks layering and how a datasource layer helps.
    The problem is that there seems to be more than one definition of the term "layering" going around. My infrastructure follows the definition that I was introduced to several years ago. Others in this forum are compaining that my infrastructure does not conform to their definition of layering. I am saying that as I do not accept this alternative definition I do not care.

    Quote Originally Posted by Brenden Vickery
    The problems here are that, the fact you are using a relational database is known, your database schema is known, you couldnt substitute an alternative layer for a different datasource. (etc. as has already been explained)
    I do not anticipate writing applications that use a data source other than a relational database, so is this really a restriction?

    One of the objectives of the 3-tier architecture is that you should be able to switch from one dbms to another simply by changing the data access layer. None of the other layers (presentation, business) should be aware of the switch. I have achieved this in my infrastructure, therefore my implementation is correct. It is different from what others in this forum may produce, and I am attacked because of this difference. I am told that my implementation is "wrong" because it breaks certain "rules", but as these "rules" do not exist in any definiton of the 3-tier architecture that I have read I see absolutely no reason why I should abide by them.

  14. #64
    SitePoint Enthusiast
    Join Date
    Apr 2004
    Location
    US
    Posts
    51
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    thats fine..

  15. #65
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mjlivelyjr
    By having any SQL fragements in your presentation layer creates a dependancy within your presentation on SQL. For example, if the database gods decided one day to radically alter SQL then you would have to make changes to your presentation layer because it has that dependency (or knowledge if you will) of SQL. SQL is obviously something that should be in the Data Access (Infrastructure) layer and if we are talking a 3 tiered application the presentation layer should have absolutely no dependancy on your data access layer.
    I anticipate that every application that I write will have a relational database as its data source, so I do not view this as a "restriction" in my infrastructure.

    I do not anticipate that the database gods will radically alter SQL at any time in the future, so I do not view this as a "restriction". If such a change were to happen I think you may find lots of other people who had applications that were suddenly *broken*. This argument is unrealistic.

    Quote Originally Posted by mjlivelyjr
    I have not read through this entire thread and I don't particularly care to take the time too, but I would wager to guess people aren't telling you that you are wrong because they don't think your methods work.
    My methods DO work, and have been working for the past several years. None of what I claim is *just a theory*, it is documenting what I have physically produced.

    Quote Originally Posted by mjlivelyjr
    They are telling you wrong because you claim your method adheres to a certain design principle that it does not.
    My method adheres to the principles of the 3-tier architecture as I know them, but if somebody else uses a different definition, or chooses to interpret that definition in a different way, then my method may not adhere to that alternative definition or interpretation, but is that my problem? Is not the real problem the fact that somebody has invented a new definition with a new set of rules that a pragmatist such as myself regards as a barrier to the production of effective sofware so is unworthy of serious consideraton?

    Quote Originally Posted by mjlivelyjr
    So it's not so much your method that's wrong as it is your defense of your method is wrong.
    I am defending myself with simple logic and the clear and certain knowledge that my methods actually work.

    Quote Originally Posted by mjlivelyjr
    Also, just because something works doesn't mean it's the best solution for a problem. Hence the term "best practices."
    I have never claimed that what I offer is the best solution or the only solution, just that it is an alternative solution, and one that works because I have tested it.

    There is no such thing as universally accepted "best practice". Different people have different views of what "best" really means. Just because my work does not conform to your interpretation of what is "best" does not give me cause for concern.

    Quote Originally Posted by mjlivelyjr
    Quote Originally Posted by Tony Marston
    My methods are different because

    * I may be working from a different set of rules.
    * I apply a different interpretation as to what those rules actually mean.
    My word...if anybody can apply whatever interpretation they want to any principle of programming then why on earth did I bother to go to school.
    People have been redefining, reinterpretting and misinterpretting various definitions for years. Take a look at http://www.toa.com/pub/abstraction.txt and see how people have been confusing themselves over the definitions of "abstraction", "encapsulation", and "information hiding". As you can see this is not a localised and recent phenomenon.

    Quote Originally Posted by mjlivelyjr
    Your presentation layer, by using SQL, requires you to have knowledge of how SQL works.
    I disagree. It knows that it is SQL, but not what the DAO might do with it when it assembles and executes the eventual query.

    Quote Originally Posted by mjlivelyjr
    For your viewing pleasure here are some more articles that give a definition contrary to what you are saying:

    http://www.jguru.com/faq/view.jsp?EID=125072
    http://en.wikipedia.org/wiki/3_tier
    http://www.phppatterns.com/index.php...leview/18/1/1/
    I have gone through each of those articles from top to bottom, and I cannot see anything that contradicts the definition that I have been using.

    Quote Originally Posted by mjlivelyjr
    Quote Originally Posted by Tony Marston
    I listen to what you have to say, but your interpretation of the "rules" is so far off course (compared with my own interpretation) that I just cannot take them seriously.
    Oh sorry, I didn't realize your interpretation was the one to live by.
    My interpretation is the one that I live by. Your interpretation is the one that you live by. I am not suggesting my my interpretation is the only true interpretation, but out of the several (many?) on offer it is the one that I choose. If you choose another interpretation then that is your choice. Just because my methods do not conform to your interpretation does not make them *wrong*. They are *right* according to a different interpretation.

    Quote Originally Posted by mjlivelyjr
    If your methods work and you choose to use them then more power to you. I am perfectly fine that your methods are different. What I do not like is you claim your methods accomplish something that they do not and that is loose coupling of layers and objects.
    My methods produce results, and it is results that count, not how you adhered to a set of arbitrary, artificial rules.

    Coupling is defined as:
    Describes how modules interact. The degree of mutual interdependence between modules/components. The degree of interaction between two modules. Lower coupling is better.
    My coupling is low because I can access any business object from any page controller, and a single XSL stylesheet can accept input from any database table with any number of columns. The dependency between these objects is therefore low because they are so interchangeable. I do not see how I could possibly improve on this.

    Quote Originally Posted by mjlivelyjr
    Like I said before, just because something works and it may be really easy to implement doesn't mean it's the best solution to any given problem.
    If it works and is easy to implement then it is simply something that works and is easy to implement. The word *better* can mean different things to different people, or in different circumstances.
    • Is it better because it is cheaper?
    • Is it better because it is easier to implement?
    • Is it better because it runs faster?
    • Is it better because it has more options?

    *Better* is subjective, and therefore something else which has no single, clear and unambiguous definition. (cue another argument...)

    Quote Originally Posted by mjlivelyjr
    If that were the case we would all be living in tents and computers would have never been invented.
    And we wouldn't be having this ridiculous argument.

  16. #66
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    Most people see peer review as valuable feedback and have the good grace to accept valid criticisms.
    When you actually get round to making a valid criticism I *might* be more inclined to accept it.

  17. #67
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mjlivelyjr
    The reason why your example breaks layering is because it references the column name as a column name.

    To be perfectly honest with you sometimes you can get by just fine with this method of doing things. I don't (and many others have already and will continue to agree with me) think this is necessarily the best way to do things.[/b]
    One method is to use the same name for a data item in every layer of the system

    Another method would be to use different names, but then you would have to include a mechanism to convert the names when passing data between one object and another.

    One method is simpler than the other. I am a follower of the KISS principle, so guess which one I choose?

    Quote Originally Posted by mjlivelyjr
    You aren't that far however from a widely accepted and widely used pattern. Look up Query Object in PoEAA.
    .....
    So you really aren't that far off from a design that most everyone wouldn't argue against.
    There are many different books available on design patterns. I have two, but none from Martin Fowler. The one thing that I have learned is that there is no single definition of any pattern that means the same thing to all men. There are always alternatives and variations that may be applied according your particular circumstances, or which side of the bed you got out of that morning, or which way the wind is blowing. Just because my design does not conform to a particular pattern in book A does not make it wrong when it is based on a completely different pattern in book B. It is not wrong, just different. It cannot be *wrong* for the simple reason that it works. If it did not work at all, then it would be wrong.

  18. #68
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by otnemem
    Hi Tony,

    As it has been pointed out, having a fraction of a SQL statement on your controller is going to give you the same layering problems as having the complete statement there.
    What problems? I see no steenking problems!

  19. #69
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I don't agree much with Tony's design ideas, ...
    That is your God-given right, and I am not going to complain about it.

    Quote Originally Posted by arborint
    ... but reading back over this thread he was neither the rudest nor the most opinionated.
    Good grief! Someone noticed!

    Quote Originally Posted by arborint
    Sadly, the best argument against his design is that it would make it harder to do things that you would probably never do (e.g. convert you database to a CSV file). Increasing coupling to simplfy code is a valid design decision. If you can manage the negative aspects of that decision, more power to you.
    If I read you correctly you are saying that the arguments against my ideas are academic and unrealistic? Therefore have little merit? Be careful, or the paradigm police will be after you as well.

    Quote Originally Posted by arborint
    We all know that threads deteroriate when the converstation is about who knows "the best way to do things" rather than presenting alternate approaches and letting people choose the one that works for them.
    I have never claimed that my ideas are best, simply different. Some people like my ideas, some people don't, but that's life. But when someone claims that my ideas are so different that they must be wrong .... well, that's what causes long threads like this.

  20. #70
    SitePoint Enthusiast
    Join Date
    Apr 2004
    Location
    US
    Posts
    51
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Brenden Vickery
    PHP Code:
    $query $pdm->newQuery('Team','Team.city == ?');
    $query->setRange(2040);
    $query->setOrdering('Team.name ascending');
    $teams $query->execute('Dallas');
    foreach(
    $teams as $team) {
       echo 
    $team->getName();
       foreach(
    $team->getPlayers as $player) {
          echo 
    $player->getName();
       }

    What if you want to get the total number of Team (where xxx condition), then how would you attack that problem?

    Can you show more how the PDM is actually working behind the scene?

    Thanks

  21. #71
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by arborint
    I don't agree much with Tony's design ideas, but reading back over this thread he was neither the rudest nor the most opinionated.
    I would disagree and you have just fed him a snippet that he will quote for sure.

    On an individual post basis perhaps some have been worse, but by volume of bile he beats everything in living memory. What's worse is that he constantly links to a site which is a good deal more vitriolic and offensive. A lot of his posts are so daft that you are obliged to correct them for the benefit of those newcomers who may actually want to know what a data mapper is. As you say, the thread was going very well up until that point. Right up until this vocal contributer (?) insisted on redefining all the terminology to obscure inflated claims. What chance has any sensible discussion with a barrage of such noise?

    How are we ever going to have a data access thread discussion on the forum again? Goodbye Sitepoint. Welcome to planet Marston (pop 1).

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  22. #72
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I just don't know folks, you know... I've said the SQL is in the wrong layer, and

    By having any SQL fragements in your presentation layer creates a dependancy within your presentation on SQL. For example, if the database gods decided one day to radically alter SQL then you would have to make changes to your presentation layer because it has that dependency (or knowledge if you will) of SQL. SQL is obviously something that should be in the Data Access (Infrastructure) layer and if we are talking a 3 tiered application the presentation layer should have absolutely no dependancy on your data access layer.
    This basically sums up as to why, but alas ol' Tony see's this explamation as a restriction aye?

    I don't even know why I bother, does anyone else get that feeling as well? It's like your speaking to a brick wall I suppose

  23. #73
    SitePoint Addict been's Avatar
    Join Date
    May 2002
    Location
    Gent, Belgium
    Posts
    284
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Mr. Marston, I don't know if you've read the book 'The pragmatic programmer' by Hunt et al? I'm just asking because, by your own standards, you seem to be taking a very pragmatic approach towards developing software.
    There are 2 tips in the first chapter that I'd like to present to you:

    10. It's both what you say and the way you say it.

    The things you say here on the forums aren't really that stupid or daft or whatever, it's just the way you convey your message that gets people on their high horses. Personally, I can't blame them, nor can I blame you for expressing yourself the way you do. Still, you seem like an intelligent person, so what's puzzling me a little bit is the fact that you probably know you have a certain way of putting things, and you probably know that people are gonna react heavily to it, resulting in threads ending like this one. So why do you do it? Maybe you just like to stir up things, maybe you've been all alone on your blog for too long and are yearning for some community recognition, maybe you truly want to present this community with an alternative way of developing PHP apps, I don't know, only you can tell...
    Thing is, you surely must know that by expressing yourself this way, you are just gonna trigger some heavy reactions or your postings will simply be ignored. Which brings me to tip nr. 5:


    5. Be a catalyst for change

    If you are trying to participate in a community and get something across, there are probably more effective ways (and less community-harming ways). Now you are boiling the frog instead of the stones
    Per
    Everything
    works on a PowerPoint slide

  24. #74
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    I just don't know folks, you know... I've said the SQL is in the wrong layer, and
    By having any SQL fragements in your presentation layer creates a dependancy within your presentation on SQL. For example, if the database gods decided one day to radically alter SQL then you would have to make changes to your presentation layer because it has that dependency (or knowledge if you will) of SQL. SQL is obviously something that should be in the Data Access (Infrastructure) layer and if we are talking a 3 tiered application the presentation layer should have absolutely no dependancy on your data access layer.
    My whole application is built on the assumption that the data source will be SQL compliant, so any "dependency" on SQL does not cause a problem. Why cater for a possibility that is never going to happen?

    The chances of the database gods changing the rules or syntax of SQL are not worth considering, as virtualy ALL of the existing applications IN THE WHOLE WORLD would be broken, not just mine. Again, why cater for something that is not going to happen?

    SQL fragments are not assembled into complete queries and executed in any other place than the data access layer. The fact that parts of those queries may originate in the presentation or business layers does not create any "dependency" between those layers, therefore there is no problem that requires a solution. Can you show me any authorities on the 3-tier architecture which identify this as a problem?

    Quote Originally Posted by Dr Livingston
    I don't even know why I bother, does anyone else get that feeling as well? It's like your speaking to a brick wall I suppose :
    Funny. That's just how I feel.

  25. #75
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You have no right to feel that way, as in my view you have contributed absolutely nothing to this discussion, except maybe to get up folks backs.

    Also, in the event that SQL does change, it's not really about an application breaking, it's a maintenance issue, even you should realise that one huh?

    In your application you'd proberly not only need to alter your DAOs but also your SQL in the templates/views/whatever; that is two area's to refactor in your case, whereas if you put the SQL where it belongs in the Model you have only the one area to refactor.

    But then again, I don't know a -BEEP- thing of what I'm talking about, do I?


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •