SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 32 of 32
  1. #26
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A few comments;

    PHP Code:
    class Jar 
       function 
    openJar() { 
          ... 
       } 


    Jar::openJar(); 
    In a way, I think you're right - if you're using the :: operator alot, you almost might as well put openJar in a normal function, if that's all you use it for.

    The :: operator allows you to run a method from a class, without having to instantiate the entire class.

    My feeling is (but perhaps I'm wrong) is there's only really one good reason to use ::, and that's when you've extended a parent class, instantiated the child but need the parent constructor method to be run (because it won't be by default.

    So for example;

    PHP Code:
    class Jar 
       function 
    Jar () {
          
    /* Creates a Jar */
       
    }
       function 
    openJar() { 
          ... 
       } 


    class 
    Jam extends Jar {
       function 
    Jam () {
           
    Jar::Jar();
           
    $this->openJar();
       }
    }

    $jam= new Jam
    When I've started making too much use of ::, the code quickly becomes a mess.

    Another thing is relationship between model and database accessing code. HarryF has separated these into two classes and I've seen it elsewhere too. I understand the need for database abstraction layer but for me business logic and sql seem to very be tightly related. I fact, usually sql contains all the business logic I have. What do I gain when I separate sql from business logic?
    One example I can think of where SQL should be "lower down" would be where web services are concerned - if your data could come from either your database or from a remote server using some XML message format, you'd need to be able to switch from one to the other.

    And for another very different way of building queries, have a look at the example here: http://www.extremephp.org/documentation.php

  2. #27
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have a controller and model class. Model needs to use database and it needs to know about current user (allow something for some users and disallow for others). If I make db connection in controller (using for example basic auth usename and password) and hand it to model then I need to pass username and password also, if I leave connecting to model, then I have to pass only username and password. And controller shouldn't care, whether model needs a database access at all or not. So it seems to me that making database connection in the model is better.
    It all depends on what your 'controller' and 'model' are. I don't get a very clear idea of what you mean by those in your example. My idea is that
    - There is some sort of datasource
    - Specific data is extracted from the datasource in some way
    - Something is done with the extracted data

    For a particular example, this could be:
    - Datasource: MySQL, database 'books'
    - Data: 'SELECT * FROM book'
    - Action: print all books in an HTML table

    If you think about your code a bit, you can write it so that the 'SELECT * FROM book' part needn't know exactly where that data comes from. In this case it's MySQL, but it could just as well be PostgreSQL, or MS-SQL Server, or whatever. Similarly, for the code that prints the books, it shouldn't matter how the data being printed is acquired. In this case it's done by executing a SELECT-statement, but it could just as well be by reading a flat textfile. By writing independent pieces of code, you get various advantages:
    - Solutions can be mixed and matched. Need a different DB? Just replace the datasource part; the rest of the code needs no changes at all.
    - Code is understandable, readable and maintainable. Because all code for a particular task is grouped together, maintaining the code is easy. Also, there's no need to fear the possibility of other parts of the code breaking down (because the parts are independent)
    - Code can be reused. You can take various parts from one application and immediately employ them in another one. Maybe you combine the parts in a different way, but you still use the same parts.

    I hope this also answers the question of why you'd want to separate the database access code from the business logic.

    Third. Vincent, you said, it's wrong to have selects, updates and inserts together in one class. I still don't understand why. Can you please explain it further?
    First of all, I didn't say it was wrong. I said:

    Inserts/Updates/Selects(/Deletes) are all in a single class. Why? Maybe inserts and updates have something to do with each other, but selects are very different. For updates you need safety and transactions; for selections all you need is a valid database connection.
    But clearly, that doesn't answer you question.

    When you select data from a database, you are always executing read-only actions. When a selection query fails, nothing has been done to the database. All you do is dump data in a way that allows you to easily use it (using joins, where clauses and so on). On the other hand, when you're changing data (inserts/updates/deletes), you're changing the internal representation of the database. That is a whole different thing. If selections are apples, then updates are oranges. However big your selection query is, you can never destroy the (internal consistency of the) database. With updates you must be very careful not to break consistency. When an update consists of multiple queries (1 * INSERT, 2 * UPDATE for example) you have to ensure that either all three queries are executed successfully, or none at all is.

    Now, when you're writing code to execute selections and updates, you'll find that both tasks need a lot of different code, and share very little, except the database connection. As a result, putting all actions in a single class will only result in one big bloated class that is marginally used: if you're executing a selection query, three quarters of the code in the class isn't used at all. By writing multiple classes you can end up with simpler and more efficient code.

    Vincent

  3. #28
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A few comments:

    Model / View / Controller (MVC) isn't very clear in a web-based application. In a 'traditional' desktop application the roles of MVC are:
    Model: The data + behaviour objects
    View: The user interface / presentation, so i.e. the windows and buttons
    Controller: something that knows how to react when the user clicks on a button of the view.
    (I'm probably not very good at explaning this, so take a look at www.martinfowler.com/isa/mvc.html)
    Now in a web application, it's obvious what the Model (data) and the View (HTML output) are, but the Controller? You tell me, I'm not sure myself either

    HarryF: One example I can think of where SQL should be "lower down" would be where web services are concerned - if your data could come from either your database or from a remote server using some XML message format, you'd need to be able to switch from one to the other.
    I think you're talking about layers in software. I'm currently trying to design a framework that has these principal layers: Presentation (HTML), Controller (sort of mediator between Presentation and Model), Model (the data + business logic), Data Mapper (responsible for finding, loading, inserting, updating, deleting Model objects from and to the database), Data Source (the SQL database).

    I'm basing this design on the upcoming book by Martin Fowler that can also be read online at www.martinfowler.com/isa/index.html.

    I'd really recommend anyone who's interesting in learning more about designing object-oriented and layered (especially) web applications to read the pages of that site, they are really interesting. I think I read each one about ten times already

  4. #29
    SitePoint Enthusiast
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    27
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    First OOP effort

    Well, I decided I'd try out OOP by making an extremely simple program, just for practice. One runs this file with a query string of something like "7*8" or "20/4" and it performs the appropriate calculation (it only does multiplying and dividing). It does seem like this program would be shorter (less lines) if I wrote it procedurally, but the impression I got is for really simple programs like this, it usually takes more code in OOP.

    I'm just posting this code for critique, I want to see if I have a basic grasp of OO design or not. :)

    PHP Code:
    <?php

    class Calculator {
        var 
    $result;

        function 
    Calculator($string) {
            if (
    strpos($string'*') !== FALSE$class 'Multiplier';
            elseif (
    strpos($string'/') !== FALSE$class 'Divider';
            else die(
    'No valid calculation indicated.');

            
    $cruncher = new $class($string);
            
    $this->result $cruncher->result();
        }

        function 
    getResult() { return $this->result; }
    }

    class 
    Cruncher {
        var 
    $first;
        var 
    $second;

        function 
    explode($string$char) {
            list(
    $this->first$this->second) = explode($char$string);
        }
    }

    class 
    Multiplier extends Cruncher {
        function 
    Multiplier($string) {
            
    $this->explode($string'*');
        }

        function 
    result() {
            return 
    $this->first $this->second;
        }
    }

    class 
    Divider extends Cruncher {
        function 
    Divider($string) {
            
    $this->explode($string'/');
        }

        function 
    result() {
            return 
    $this->first $this->second;
        }
    }

    $calc = new Calculator($_SERVER['QUERY_STRING']);
    echo 
    $calc->getResult();

    ?>
    Last edited by ThreeDee; Sep 27, 2002 at 17:20.

  5. #30
    FreeBSD The Power to Serve silver trophy pippo's Avatar
    Join Date
    Jul 2001
    Location
    Italy
    Posts
    4,514
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi Captain Proton,
    I use this thread to say a big thank you for the link you provide about martin fowler book.
    You did post it many times ago but I'm very thankful to you for that link because it's a very inspiration muse...

    This is a little tribute to you that segnalated that link because as a Man said 2000 years ago...Give To Ceaser What Is Of Ceaser's



    pippo

    p.s.
    I'm going to compile a list to submit to sean for a top thread here, so you and other can pm to me similar links.
    They will be put inside an unique thread for reference.
    Mr Andrea
    Former Hosting Team Advisor
    Former Advisor of '03

  6. #31
    SitePoint Member
    Join Date
    Sep 2005
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Pear Db how to store query reesults in a global array

    Well hi, i want to store the results of a returned sql query in a global array and then use that array containing the results later for querying further..

    do someone have an idea how to do it with pear db...
    i also need to use a for loop to continue to iterate the query further...

    can someone help me out plz or know the codes how to do it...
    any help will be most welcome...

    Thanks in advance....

  7. #32
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Take a look at PoEAA, in particular Identity Map could be what your looking for,

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


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
  •