SitePoint Sponsor

User Tag List

Page 4 of 5 FirstFirst 12345 LastLast
Results 76 to 100 of 110
  1. #76
    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
    There are many different books available on design patterns. I have two, but none from Martin Fowler.
    With all due respect Mr. Marston, why are you quoting text from a book you do not have then? PoEAA is quite possible one of the most important books to have in your library if you write any kind of enterprise or even "close to enterprise" type software. I highly reccomend that you buy it or at least get it from your local library. Reading it will give you a much better idea of why we are saying what we are saying.

    I think you are taking my post and thoughts completely out of context. I have not a single time said your method for doing things is wrong. I have said it is probably not the best way...that is worlds apart from being wrong.

    You are also right in that there is no universally accepted best practices. There are however widely accepted best practices. Now for another point of clarifications. Sometimes the best practice isn't always the best practice. That is why whenever you look through any pattern catalog that is worth anything it will list the pros and cons of each pattern. There isn't and there never will be a perfect solution. The solution has to fit the problem. If your given solution fixes the problem...then that's great.

    I don't think if you asked any one of us we would tell you your solution is wrong in the functional sense of the word. We would recommend that it be avoided for the fact (I'm sorry if you disagree, it's your right) that it breaks the layering concept. What was being done here was we were pointing out a "con" to your solution. Just like any solution yours is going to have pros and cons. If you are so bold to say that your solution has no cons....

    Quote Originally Posted by Tony Marston
    Coupling is defined as: Quote:
    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.
    That is not low coupling. Read the definition again. Low Coupling is defined as (this is straight from your definition) A low degree of interaction between two modules. Interaction can also read dependancy. If two objects can interact then they are inherently dependant on eachother pending the direction of the interaction. Now, you proceed to say after this quote that you can access any business object from any page controller. This in and of itself doesn't make for low coupling. In fact it can be the exact opposite depending on how you implement it. I won't flat out say you are wrong only because I don't know enough about the internals of your application code. I will say however that you haven't provided enough proof to say that your code is loosely coupled. Past that, your page controller and your business objects may be loosely coupled, but coupling in your system is increased by using SQL (whether it be in whole or in part) in your controller. Whether or not SQL is seen as something that will change or remain constant doesn't matter, your controller code is dependant on SQL and as such has an added coupling to SQL. What makes most of us cringe is that this particular coupling skips over an entire layer in your code. For you application this may work just fine for you. It does however limit the flexibility and scalability of your code. You will never be able to use it with any data storage system that doesn't use SQL without significant code changes. That is why it breaks the layering principle. Your application is tightly coupled to SQL. This goes against pretty much every article and quote I listed in one of my previous posts. Now, I can't make this point enough (apparently.) I'm not saying your code doesn't work. I am just saying that lastcraft was right way back on the second page when he said your design breaks layering.

    Now, to be perfectly honest with you I use to do things almost exactly the same way as you did. I had a class that was capable of building pretty much any query I needed through a series of function calls. I too made these calls in the controller and occasisionally even further up in the "presentation" layer. This worked great on the small projects that we were getting at the time and I had never really heard or read anything different. As the projects I was working on became larger however this style of coding became extremely un-manageable. I had queries getting built all over pages of the site and it became a rather large hassle to change even simple things like default orderings.

    Now I am begining to use more of a Domain Model accompanied by Data Mappers (via PoEAA) for my architecture. I have actually just begun reimplementing some of our current software using this style. I will admit that for small projects this is usually overkill. However, quite frankly my current job doesn't really deal with small projects much. So the architecture works great. If I want to hire a new developer to help I don't have to train them how to use my code, as long as they have a decent understanding of Domain Models and Data Mappers then they will do just fine, if they don't have an understanding it is rather trivial for most developers to pick up a book and read about the patterns I am using. If the developer doesn't want to do this, then quite frankly I wouldn't be willing to hire them.

    In closing, I just want to say one more time. I never have and I probably won't say your way is wrong. The only claim I am making is that it breaks layering. You can argue with that point if you want to, but take a look back at this thread, not a single person agrees with your statements about how your design complies with layering.

    I again highly recommend you pick up a copy of PoEAA. In fact, I'll make a deal with you. If you give me the names and authors of the two patterns books you are using to justify your position then I will get them within the week and read through them. It would serve you well to have at least a couple authoritative quotes to justify your thoughts on layers.

    Oh, and did I mention your way of doing things isn't wrong?
    Mike Lively
    Digital Sandwich - MMM MMM Good

  2. #77
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston
    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.
    Not being able to switch to another data source is a problem whether that data source is an OO Database, an Relational Db or an XML file. Being able to make that switch is the point of the data source layer and if you know youll never need to make any changes to how you access your data source then you dont need a data source layer.

    Being able to switch to different RDMS isnt enough to call your layer a data source layer in the 3 tier sense. That would be like Java people calling JDBC a data source layer, or php people calling adodb a data source layer and putting sql in the controller.

    Its kind of like someone telling you this is MVC:
    PHP Code:
    class Controller {
        function 
    execute($request) {
            
    $customerMapper = new CustomerMapper();
            
    $customers $customerMapper->findAll();
            
            
    $customersHTML '<ul>';
            foreach(
    $customers as $customer) {
                
    $customersHTML '<li>' $customer->getFirstname() .
                                 
    ' ' $customer->getLastname() . '</li>';
            }
            
    $customersHTML '</ul>';
            
            
    $tpl = new Tpl();
            
    $tpl->set('customers'$customersHTML);
            
    $tpl->render();
        }

    Having even the slightest bit of HTML in the controller breaks the seperation. If you know you will never need to change how that list will work and you know you will never need to change to a XUL interface thats fine to put the html in the controller but its broken MVC plain and simple.

  3. #78
    SitePoint Zealot
    Join Date
    Jun 2004
    Location
    Bogota
    Posts
    101
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston
    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.
    Quote Originally Posted by Tony Marston
    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! Today 05:49
    Ok, First of let me ask you what's your real goal when you starting using your 3 tier architecture?

    As you said, one of the reasons one might want to have the data access in a different layer is to be able to switch databases. If you achieve the separation correctly non of the layers above need to be changed above, so you and the people that work with you will worry less about breaking something in the top layers. It makes the code easier to mantain.

    If you don't plan to support different databases then there's one reason less to have this kind of layering... But hey, it is not the only reason why you want to have a data access layer.

    In my case (which might be the case of many others) we have a lot of queries that involve different type of filters or joins. We work constantly on optimizing these queries and optimizing the db schema. That's how we learn that the database might evolve at a different rate and we don't want to be updating all the layers every time we change a query. Another reason is when you want to upgrade your current database which is much more likely than just changing it. When we upgraded our database from mysql 3 to mysql 4 there were new features supported and a couple of others unsupported. There was a date comparison that broken after the upgrade which caused problems in different parts of the system.

    This is very hard to track if you have to look for sql statements (or fragments) through out different layers. The logical place to look for it is in the DAO (in your case) or any other persistance framework you choose.

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

  4. #79
    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
    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?
    But it is NOT liable to change, is it? So NOT having the ability to cope with a change that is NOT liable to appear is NOT a limitation worth serious consideration.

  5. #80
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mjlivelyjr
    With all due respect Mr. Marston, why are you quoting text from a book you do not have then?
    Because other people have used quotes from his book in various posts. I have also visited his website at http://www.martinfowler.com/. I am finding that some of his quotes give some support to my own views, so why not use them?

    Quote Originally Posted by mjlivelyjr
    I think you are taking my post and thoughts completely out of context. I have not a single time said your method for doing things is wrong. I have said it is probably not the best way...that is worlds apart from being wrong.
    I'm sorry. I am using the global *you* to encompass all those who attack me in this forum for breaking rules that do not exist. If that does not include you then I apologise.

    Quote Originally Posted by mjlivelyjr
    I don't think if you asked any one of us we would tell you your solution is wrong in the functional sense of the word.
    A solution can only be wrong if it doesn't work. The fact that it may break an artificial set of rules does not make it wrong, it simply brings into question the validity of those rules.

    Quote Originally Posted by mjlivelyjr
    We would recommend that it be avoided for the fact (I'm sorry if you disagree, it's your right) that it breaks the layering concept.
    Yes, I do disagree. Each of my layers is valid as it does exactly what it is supposed to according to all the descriptions of the 3-tier architecture that I have ever read.

    Quote Originally Posted by mjlivelyjr
    What was being done here was we were pointing out a "con" to your solution. Just like any solution yours is going to have pros and cons. If you are so bold to say that your solution has no cons....
    Certainly not. Every solution, including mine, has its pros and cons. It is a balance of different options and requirements. To be strong in one area is liable to cause a corresponding weakness in another. Some people insist on a particular strength and are prepared to accept any resulting weakness.

    Quote Originally Posted by mjlivelyjr
    Quote Originally Posted by Tony Marston
    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.
    That is not low coupling. Read the definition again. Low Coupling is defined as (this is straight from your definition) A low degree of interaction between two modules. Interaction can also read dependancy. If two objects can interact then they are inherently dependant on each other pending the direction of the interaction.
    Low coupling tends to create more reusable methods. It is not possible to write completely decoupled methods, otherwise the program will not work!

    Low dependency tends to create more reusable code, and makes it easier to reuse the same code in different projects.

    I have very high levels of reusability, and have reused the same code in several applications, therefore my levels of coupling and dependency must be low enough

    Quote Originally Posted by mjlivelyjr
    Whether or not SQL is seen as something that will change or remain constant doesn't matter, your controller code is dependant on SQL and as such has an added coupling to SQL.
    My controller code is not *dependent* on SQL, it simply has the option to provide some fragments of it if it needs to. There is no *dependency*.

    *Coupling* is to do with connections between components. The passing of SQL fragments as pieces of data does not fall into this category (IMHO) therefore there is no problem wuth coupling that I can see.

    Quote Originally Posted by mjlivelyjr
    What makes most of us cringe is that this particular coupling skips over an entire layer in your code.
    How? My presentation layer does not communicate with the data access layer. It communicates with the business layer. It is only the business layer that communicates with the data access layer.

    Quote Originally Posted by mjlivelyjr
    It does however limit the flexibility and scalability of your code. You will never be able to use it with any data storage system that doesn't use SQL without significant code changes. That is why it breaks the layering principle. Your application is tightly coupled to SQL.
    Considering I am in the business of designing and building applications that all use SQL databases why is this a problem? Why should I allow for situations that I will never have to deal with?

    Quote Originally Posted by mjlivelyjr
    This goes against pretty much every article and quote I listed in one of my previous posts. Now, I can't make this point enough (apparently.) I'm not saying your code doesn't work. I am just saying that lastcraft was right way back on the second page when he said your design breaks layering.
    Considering the fact that I am only going to write applications that use SQL databases, having a correct implementation of the data access layer will allow me to swtch from one RDBMS to another simply by changing my data access layer. This I can do, so my implementation is not broken.

    Quote Originally Posted by mjlivelyjr
    Now, to be perfectly honest with you I use to do things almost exactly the same way as you did. I had a class that was capable of building pretty much any query I needed through a series of function calls. I too made these calls in the controller and occasisionally even further up in the "presentation" layer.
    That is where my implementation differs. My presentation layer may generate SQL fragments, or pieces of information that will eventually be used to generate an SQL query, but all it does is pass them to the business layer as data.

    The business layer may massage any one of these pieces of data, but apart from that it does nothing with them except pass them to the data access layer.

    Within the data access layer my DAO will take these individual fragments and assemble them into the right SQL query then execute it before passing the results back to the business layer. Note that I have a separate DAO for each different DBMS engine, therefore each DAO has the opportunity to assemble the SQL query in just the format required by that particular DBMS. Therefore to switch from one DBMS to another all I have to do is switch the DAO. The SQL fragments in the presentation and business layers remain the same, it is only the way that are assembled which needs to change.

    I repeat, pieces of SQL may appear anywhere, but they are only assembled and executed within the DAO.

    Quote Originally Posted by mjlivelyjr
    I again highly recommend you pick up a copy of PoEAA. In fact, I'll make a deal with you. If you give me the names and authors of the two patterns books you are using to justify your position then I will get them within the week and read through them. It would serve you well to have at least a couple authoritative quotes to justify your thoughts on layers.
    (1) "Design Patterns" by Gamma, Helm, Johnson & Vissides
    (2) "A System of Patterns" by Buschmannn, Meunier, Rohnert, Sommerlad & Stal

    Quote Originally Posted by mjlivelyjr
    Oh, and did I mention your way of doing things isn't wrong?
    Can I quote you on that?

  6. #81
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston
    I repeat, pieces of SQL may appear anywhere, but they are only assembled and executed within the DAO.
    This would appear to be the essence of the disagreement. Would you care to provide a page reference to
    (1) "Design Patterns" by Gamma, Helm, Johnson & Vissides
    or
    (2) "A System of Patterns" by Buschmannn, Meunier, Rohnert, Sommerlad & Stal
    which more or less says this or has a code example which exhibits it?
    Zealotry is contingent upon 100 posts and addiction 200?

  7. #82
    Node mutilating coot timnz's Avatar
    Join Date
    Feb 2001
    Location
    New Zealand
    Posts
    516
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston
    A solution can only be wrong if it doesn't work. The fact that it may break an artificial set of rules does not make it wrong, it simply brings into question the validity of those rules.
    You'd be great at PR. But to counter your point, the artificial set of rules I don't think say a solution WON'T work if it breaks them, which is what you imply here. But now we're confusing with the issue raised earlier of different interpretations of the rules.

    In terms of the interpretations you use, your scheme gives you the highest karma. In terms of the interpretations used by those disagreeing with your interpretations, their's give them their highest karma. If you're to use each other's interpretations then you each individually feel your karma decrease.

    Quote Originally Posted by Tony Marston
    I repeat, pieces of SQL may appear anywhere, but they are only assembled and executed within the DAO.
    This is the part that scares me. If I want to change or optimise a particular query I have to look in multiple places to do so. Personally I find maintainance like this easier if it's in one place.

    Just because they're not used in any of the layers except the proper one, in my own interpretations, I don't feel comfortable having the fragments spread like that. Does that make me cuckoo? No, probably not, just makes me feel like I've higher karma.
    Oh no! the coots are eating my nodes!

  8. #83
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So let me get this straight. This is a long (and getting boring) tread about which is better, this:
    PHP Code:
    $person->getWithLastname($lastname); 
    or this:
    PHP Code:
    $person->getData("lastname=\"$lastname\""); 
    Honestly, both directions have their pros and cons. But is either the "He had SQL in his Presentation Layer, BURN HIM!" or Tony's absurdly long, thread destroying replies really necessary? I'm still wanting to learn more about Brenden's data mapper.

  9. #84
    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
    Because other people have used quotes from his book in various posts. I have also visited his website at http://www.martinfowler.com/. I am finding that some of his quotes give some support to my own views, so why not use them?
    I wouldn't recommend making quotes from books you haven't read, tends to give the quotes less credibility especially if we know you haven't really read them in context.

    I'll say it again, the point of patterns isn't to lock you into a set of rules. Patterns themselves are NOT rules. They are best practices. Even the term 'best practices' doesn't really describe them well. My best thought description of a pattern is this: A well documented way of achieving a solution to a particular problem. By well documented I mean that each pattern has documented pros and cons. The only time that rules come into play is whether or not your code follows the guidelines of the pattern. If you break these guidelines (or rules if you will) then it doesn't make your code wrong it just means your code isn't an example of that particular pattern. Not wrong, not right, just different. The only thing I am disagreeing with you about (well the only thing that really matters) is that you claim your code adheres to the commonly accepted description of a 3-tiered structure.

    Quote Originally Posted by Tony Marston
    Low coupling tends to create more reusable methods. It is not possible to write completely decoupled methods, otherwise the program will not work!

    Low dependency tends to create more reusable code, and makes it easier to reuse the same code in different projects.

    I have very high levels of reusability, and have reused the same code in several applications, therefore my levels of coupling and dependency must be low enough
    This is just bad logic. Take the following:
    Code:
        Dogs have legs
        I have legs
        I am a dog
    Doesn't make much sense. It is an incorrect connection of the first two truths that result in the third statement which is an obvious fallicy. (well, some may think I am a dog, but that's a topic for another thread.)

    Code:
        Decoupled code is reusable
        My code is reusable
        My code is decoupled
    Same kind of logic. I do agree that your code is probably decoupled. If anybody ever writes anycode that isn't decoupled at all then they need to look at a new line of work . However I honestly don't think your code is as highly decoupled as it could be. That's all I'm saying. Again is it wrong? No, it's just how you do it. Does the level of coupling break the general view of a 3-tiered application? I think so. I'll explain why in a bit.

    Quote Originally Posted by Tony Marston
    My controller code is not *dependent* on SQL, it simply has the option to provide some fragments of it if it needs to. There is no *dependency*.

    *Coupling* is to do with connections between components. The passing of SQL fragments as pieces of data does not fall into this category (IMHO) therefore there is no problem wuth coupling that I can see.
    I don't know that your view on dependancy is entirely accurate. It may not seem like your controller is depending on SQL because it's not using full fledged SQL statements. However, let me ask you this. If you take a controller that is providing SQL fragments, and you decide you want to change the underlying database to a data system that doesn't use SQL will you have to make changes to your controller? If the answer is yes then that means your controller is dependent on SQL. Now you may say "I won't ever change away from SQL." That isn't the point, I am just saying your code is dependant on SQL. I am not even really saying that it's bad to depend on SQL in your controller. I am just saying it's not 3-tiered.

    The controller class is dependant on SQL. SQL is part of the data storage system. The data system lies in the data access layer. Follow the chain and you see that the controller class is dependant on the data access layer. Follow that one step further and it says your presentation layer is dependant on the data access layer.

    I also do not think I was clear when I described my old implementation. The calls I made in the controller would (like your examples) set hard coded criteria by constructing WHERE statements via a call such as $dataModel->setWhere("col1 = 'value' AND col2 = 'value'"); So like you I was coding dependancies on the data access layers (SQL) into my presentation layer (controller)

    Oh, and you may quote me as long as it is in context

    I also urge you to post some quotes from "Design Patterns" to strengthen your position. I don't think anybody here will argue against any member of the GoF.

    Off Topic:


    It would be nice if a friendly monitor could split the thread. I was reading through the first page and there was actually some very intelligent conversation.
    Mike Lively
    Digital Sandwich - MMM MMM Good

  10. #85
    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
    Not being able to switch to another data source is a problem whether that data source is an OO Database, an Relational Db or an XML file. Being able to make that switch is the point of the data source layer and if you know youll never need to make any changes to how you access your data source then you dont need a data source layer.

    Being able to switch to different RDMS isnt enough to call your layer a data source layer in the 3 tier sense.
    In some people's eyes it is. Take this quote from http://www.phppatterns.com/index.php...leview/18/1/1/
    Each layer should be interchangeable. This results in some further rules;
    • Each layer should have a clearly defined data interface (API: application program interface).
    • Layers should expect nothing of other layers except that they use the defined APIs to exchange data.

    The data access tier, for example, should not expect a particular database, such as Oracle, to reside below it. In other words it should be possible to replace Oracle with an alternative database without any impact on the data access tier (or any tiers above it).
    My implementation conforms to that description. That's good enough for me. If I want to access a particular DBMS I simply plug in the DAO for that DBMS. This will give me the ability to develop web applications that will work with any popular database such MySQL or PostgreSQL. I am not limiting my options to just one.

  11. #86
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If thats good enough for you, thats good enough for me. Im not going to argue with that except to quote the same page about 2 paragraphs up.
    #4 Data access tier: [e.g server running JDBC] all data I/O to data repositories handled here for example connects to database, fetches data from various sources including files, XML documents, spread sheets and so on.
    #5 Data tier: [e.g a database] application data is stored here in repositories - perhaps a database, perhaps text files, perhaps even an XML database like the Apache Groups XIndice

  12. #87
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by otnemem
    Ok, First of let me ask you what's your real goal when you starting using your 3 tier architecture?
    My purpose in implementing the 3-tier architecture is so that I can make changes in any one of the layers without having to make corresponding changes in any of the other layers. This includes switching to another UI, or switching to another DBMS. That is one of the stated purposes of the 3-tier architecture. Easier development and easier maintenace are others.

    Quote Originally Posted by otnemem
    As you said, one of the reasons one might want to have the data access in a different layer is to be able to switch databases. If you achieve the separation correctly non of the layers above need to be changed above, so you and the people that work with you will worry less about breaking something in the top layers. It makes the code easier to mantain.
    Agreed. I have discovered that for myself in the four years since I implemented my first 3-tier architecture in a previous language.

    Quote Originally Posted by otnemem
    If you don't plan to support different databases then there's one reason less to have this kind of layering... But hey, it is not the only reason why you want to have a data access layer.
    But I do plan to support multiple databases. I plan to develop applications that will run on either MySQL or PostgreSQL (and others too, when I get the time to write the DAOs). That way I am not tied to a single DBMS.

    Quote Originally Posted by otnemem
    In my case (which might be the case of many others) we have a lot of queries that involve different type of filters or joins. We work constantly on optimizing these queries and optimizing the db schema. That's how we learn that the database might evolve at a different rate and we don't want to be updating all the layers every time we change a query. Another reason is when you want to upgrade your current database which is much more likely than just changing it. When we upgraded our database from mysql 3 to mysql 4 there were new features supported and a couple of others unsupported. There was a date comparison that broken after the upgrade which caused problems in different parts of the system.
    I made the decision two years ago to stick to standard SQL as much as possible, and not to make use of features that were unique to a particular DBMS (such as MySQL's auto-increment feature). I balance any possible losses by the gains of having applications that can be deployed on any popular DBMS.

    Quote Originally Posted by otnemem
    This is very hard to track if you have to look for sql statements (or fragments) through out different layers. The logical place to look for it is in the DAO (in your case) or any other persistance framework you choose.
    I repeat, the fact that fragments of SQL statements may appear in other layers is not the great problem that you make out. These fragments are given to the DAO as separate pieces, and the DAO does whatever is necessary to construct and execute a query that is valid for its designated DBMS. I don't have to go back to the other layers to change these SQL fragments before they are given to the DAO as I have the ability to change them after they are given to the DAO. Do you see my logic?

  13. #88
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by auricle
    This would appear to be the essence of the disagreement. Would you care to provide a page reference to
    (1) "Design Patterns" by Gamma, Helm, Johnson & Vissides
    or
    (2) "A System of Patterns" by Buschmannn, Meunier, Rohnert, Sommerlad & Stal
    which more or less says this or has a code example which exhibits it?
    I cannot point to any chapter and say "this says that what I am doing is valid", just as you cannot point to any chapter and say "this proves that what you are doing is invalid".

    Design patterns simply give a high-level picture and leave implementation details up to the individual. They do not require a particular implementation, so none of these books contains any code snippets which are of any use to anybody in this particular discussion.

  14. #89
    SitePoint Guru
    Join Date
    Dec 2003
    Location
    oz
    Posts
    819
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Each layer should be interchangeable. This results in some further rules;
    • Each layer should have a clearly defined data interface (API: application program interface).
    • Layers should expect nothing of other layers except that they use the defined APIs to exchange data.
    The data access tier, for example, should not expect a particular database, such as Oracle, to reside below it. In other words it should be possible to replace Oracle with an alternative database without any impact on the data access tier (or any tiers above it).
    Well, I have seen many opinions differing in whether each layer only concerns itself with the one below, or any layers below.

    Both domain layer and app layer use components from the infrastructure layer, which sits at the bottum, and the gui layer (depending on whose opinion it is) can use objects from the domain layer.

    I think there is no right or wrong answer for this. You could insulate each layer if you feel it is necessary, or you could allow a layer to access the layers below.

    Although, it does seem to be the case that the data abstraction layer is generally the only way through to the database, so this (data persistence) can be swapped. Is this a special case, or should we ensure that out application layer also insulates the gui from the domain? I'm wondering if best practices would be to add this insulation layer, but for small apps you could forgoe it (just as you collapse more and more layers as the system size is reduced).

    Regards,
    Eli

  15. #90
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by timnz
    Quote Originally Posted by Tony Marston
    I repeat, pieces of SQL may appear anywhere, but they are only assembled and executed within the DAO.
    This is the part that scares me. If I want to change or optimise a particular query I have to look in multiple places to do so. Personally I find maintainance like this easier if it's in one place.
    I repeat, the fact that fragments of SQL statements may appear in other layers is not the great problem that you make out. These fragments are given to the DAO as separate pieces, and the DAO does whatever is necessary to construct and execute a query that is valid for its designated DBMS. I don't have to go back to the other layers to change these SQL fragments before they are given to the DAO as I have the ability to change them after they are given to the DAO. Do you see my logic?

  16. #91
    Node mutilating coot timnz's Avatar
    Join Date
    Feb 2001
    Location
    New Zealand
    Posts
    516
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston
    I repeat, the fact that fragments of SQL statements may appear in other layers is not the great problem that you make out. These fragments are given to the DAO as separate pieces, and the DAO does whatever is necessary to construct and execute a query that is valid for its designated DBMS. I don't have to go back to the other layers to change these SQL fragments before they are given to the DAO as I have the ability to change them after they are given to the DAO. Do you see my logic?
    I see you've copied and pasted your exact reply from a couple of posts above Not that it doesn't address my concern though. Regardless, I don't think you've won me over
    Oh no! the coots are eating my nodes!

  17. #92
    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
    I repeat, the fact that fragments of SQL statements may appear in other layers is not the great problem that you make out. These fragments are given to the DAO as separate pieces, and the DAO does whatever is necessary to construct and execute a query that is valid for its designated DBMS. I don't have to go back to the other layers to change these SQL fragments before they are given to the DAO as I have the ability to change them after they are given to the DAO. Do you see my logic?
    This doesn't make it any easier to optimize your database for your queries though. If you do all of the work on your DB yourself then this isn't a real big deal, you know what queries you are making you know what in your db needs optimized. However, if someone else ever gets the task to optimize the db that your app uses they will have to dig through all your controller classes, pick out the parameters passed to $object->setWhere(); (or your similar function) and that (for a larger application) can be an absolute nightmare. Whereas with more traditional datamappers and similar arrangements all of the queries are held within a few files that contain your mappers.
    Mike Lively
    Digital Sandwich - MMM MMM Good

  18. #93
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston
    When you actually get round to making a valid criticism I *might* be more inclined to accept it.
    I wouldn't waste my time. Why are you wasting ours?

  19. #94
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I'm still wanting to learn more about Brenden's data mapper.
    Its really nothing ground breaking at all. PDM is a UnitOfWork that builds a Query object that get its Criteria objects created by parsing an Object Query Language (OQL). Java does this with JDO and microsoft will eventually get into the game with Object Spaces. MS's Object Spaces is particularly interesting becuase its query language has evolved from xpath into OPath.

    Ill try to go into more depth with the code later.

  20. #95
    ********* 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 Brenden Vickery
    Its really nothing ground breaking at all. PDM is a UnitOfWork that builds a Query object that get its Criteria objects created by parsing an Object Query Language (OQL).
    Cough...! Now I'm interested !

    Fancy starting a thread to describe this. The different pieces of a Hibernate like library are coming together from different sources now. I know Jeff wants a DataMapper/UnitOfWork driven system for the persistence in WACT and another group are working on my XSLT driven Changes library I posted late last year. And of course we already have Propel. If there is enough code out there, and enough authors of these ungeneralised libraries, a PHP Hibernate project might just spring into being.

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

  21. #96
    SitePoint Enthusiast mjlivelyjr's Avatar
    Join Date
    Dec 2003
    Location
    Post Falls, ID, US
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well then, it only took 4 pages to get back on topic :P

    A quick link for those unawares of Hibernate: http://www.hibernate.org

    A PHP version of Hibernate would be a great idea actually. It would solve about half of the issues I am dealing with right now. Propel is close to all that I need but it's only part of the solution really. Heck, if anyone else is interested I'd throw my hat into the ring as a volunteer.

    Edit:

    We may need a new thread for this...
    Mike Lively
    Digital Sandwich - MMM MMM Good

  22. #97
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    naperville
    Posts
    189
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TM
    Because other people have used quotes from his book in various posts. I have also visited his website at http://www.martinfowler.com/. I am finding that some of his quotes give some support to my own views, so why not use them?
    Its dangerous to quote without context.

    Quote Originally Posted by Tony Marston
    I made the decision two years ago to stick to standard SQL as much as possible, and not to make use of features that were unique to a particular DBMS (such as MySQL's auto-increment feature). I balance any possible losses by the gains of having applications that can be deployed on any popular DBMS.
    This is somewhat related to the idea of data access.

    This is somehting I disagree on, although i might be alone in this. I'd rather use DB specific code and have it run smoothly and efficiently then limit myself to the standards. If I were to switch DB's, id just use a seperate set of DAO's and take advantage of that DB's features. I cant see myself not using stored procedures with postgre or fulltext/auto_inc with mysql. With oracle, you'll have to make even more changes. While criple your code when in all reality, DB changes happen rarely if ever? Development time and execution speed gianed by using specific SQL is likely greater then it would be if youd have to go through the DAOs and switch all the SQL.

    Thats also another argument for having all the SQL in a seperate DAO layer: if you ever want to change something, its all in one place.

  23. #98
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Cough...! Now I'm interested !
    I wouldnt get too excited. The OQL is working but writing the code to truely parse an OQL is beyond my skills. Using an OQL obviously adds overhead but the speed you at which you can write the code is the advantage.

    Id love to work on something in the persistence area, especially for WACT. The big reason Im not using WACT for projects is, that using persistence seems difficult.

    Ill start a sourceforge project for the code.

  24. #99
    SitePoint Zealot
    Join Date
    Jul 2003
    Location
    Los Angeles
    Posts
    199
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mjlivelyjr
    Well then, it only took 4 pages to get back on topic :P

    A quick link for those unawares of Hibernate: http://www.hibernate.org

    A PHP version of Hibernate would be a great idea actually. It would solve about half of the issues I am dealing with right now. Propel is close to all that I need but it's only part of the solution really. Heck, if anyone else is interested I'd throw my hat into the ring as a volunteer.
    Damn is it spooky reading all the threads lately about you guys talking about Dependency Injection,TypeSafe PHP and now Hibernate. These are the exact topics that got me intersted in Java webapps in the first place. After learning Spring which supports DI and finally getting a grip of Hibernate(which is damn complicated to get a throrough undrestanding) it tickles me to read these threads of late.

    Now all you need is Xdoclet support in your domain classes for creating the hibernate-like mapping files. It's definitely much easier to work in this top-down fashion rather than playing with messy xml mapping files and then converting those to domain class code.

    If the next thing I see is a thread mentioning AOP(Aspect Oriented Programming) I'm really going to lose it I just got AOP transaction proxy to work in Spring and it's so sweet.

    Good luck on these PHP endeavors, I hope they work out.

  25. #100
    ********* 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 Brenden Vickery
    The OQL is working but writing the code to truely parse an OQL is beyond my skills.
    If you start another thread I'l try to explain how a lexer works. We may be able to hack an OQL parser in the course of a SitePoint thread. We have got to get the discussion off of this damaged thread though. I have Marston on my ignore list, but it's still irritating seeing all of the replies.

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


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
  •