SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 57
  1. #26
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by blueyon View Post
    I was trying to be funny.
    Could be, was not the impression I got, unfortunately. Still I hope the example helps.

  2. #27
    SitePoint Evangelist
    Join Date
    Mar 2005
    Posts
    421
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The use of views to represent an interface to a composite object has got my interest - how often is this done? Is this the best method to create objects that need anything more than a left join to create? I've been advised in the past to steer away from db implementations of application logic - is there any notable downsides to using views in this manner from an object creation / update point of view? I suppose it makes the application a whole lot more dependant on the db; for instance, to delete a view, would you program all the cascading deletes in the db or application?

  3. #28
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Views are not application logic -- they're an integral part of relational databases, defined in the earliest relational theory along with entities such as tables, triggers and the like. The database's job should be to store information and present it to the application, with exact details depending on the exact data. For example, if a bank needs to retrieve a part of the customer's history according to very precisely defined rules, gathering it from a number of different tables and other places, it is just data, and the logic to retrieve it makes sense to be stored in the database, e.g. in a stored procedure or a view, whatever suits the purpose better. That way different applications may use the same data without duplicating the code.

  4. #29
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac View Post
    Views are not application logic -- they're an integral part of relational databases, defined in the earliest relational theory along with entities such as tables, triggers and the like. The database's job should be to store information and present it to the application, with exact details depending on the exact data. For example, if a bank needs to retrieve a part of the customer's history according to very precisely defined rules, gathering it from a number of different tables and other places, it is just data, and the logic to retrieve it makes sense to be stored in the database, e.g. in a stored procedure or a view, whatever suits the purpose better. That way different applications may use the same data without duplicating the code.
    How would you implement something like this in the code?

  5. #30
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've just come accross this article.

    http://blog.mikeseth.com/index.php?/...-is-wrong.html

    It explains really well about models and how alot of the other frameworks are implementing models incorrectly.

    These are the problems that the ORM data access layer (which Rails calls a "model") solves for you:


    Fetch a single post
    Save a single post
    Delete a post


    These are the problems that an actual MVC model solves for you:


    Fetch/save/delete a single post (using the underlying DAL)
    Find all posts in a given category
    Find last X posts
    Find all posts for month X
    Find X posts by author Y that aren't published yet

  6. #31
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by blueyon View Post
    How would you implement something like this in the code?
    On the application side, there is no difference between using a straightforward data entity or a complex one composed of different information from different sources. The difference is on the database side, where you employ a bunch of tools -- such as views, stored procedures and triggers -- to do the data crunching for you.

  7. #32
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by blueyon View Post
    I've just come accross this article.

    http://blog.mikeseth.com/index.php?/...-is-wrong.html

    It explains really well about models and how alot of the other frameworks are implementing models incorrectly.

    These are the problems that the ORM data access layer (which Rails calls a "model") solves for you:


    Fetch a single post
    Save a single post
    Delete a post


    These are the problems that an actual MVC model solves for you:


    Fetch/save/delete a single post (using the underlying DAL)
    Find all posts in a given category
    Find last X posts
    Find all posts for month X
    Find X posts by author Y that aren't published yet
    That article is a bit misguided. There's absolutely nothing preventing you from implementing finder methods like he describes in ActiveRecord. Some people might use active record simply as a data access layer, but that's not it's intended usage; the active record pattern, by definition, mixes data access with domain logic. Some people really get bothered about it, but it's not wrong by any means, it's simply an approach that has its benefits and its drawbacks.

  8. #33
    SitePoint Evangelist
    Join Date
    Mar 2005
    Posts
    421
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac View Post
    On the application side, there is no difference between using a straightforward data entity or a complex one composed of different information from different sources. The difference is on the database side, where you employ a bunch of tools -- such as views, stored procedures and triggers -- to do the data crunching for you.
    I understand what you're saying, but it almost seems like cheating. I'm used to writing monolithic queries - basically, you're saying the application should have only simple select statements, which obtains the (complex) data from a view?

  9. #34
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > ... you're saying the application should have only simple select statements, which
    > obtains the (complex) data from a view?

    From what I understand of Views in database relational management, yes is the answer to your question. I don't use these tools personally, as I believe that, that given complexity should remain with the application but I can understand why some would use it [Views].

    I could say it's personal preference but it's not, as there are some advantages I suppose? You just need to weigh them up against the disadvantages, which of course would be dependent on the application you have in mind.

  10. #35
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote from the blog entry from above,

    > ... Low level ORM manipulation should be contained in your models - never in
    > your controllers, actions or views. ...

    That is the problem with Ruby on Rails Active Record in regards as to how some people who use RoR, develop with. The issue the author has isn't specific to Active Record it's self as a solution, but how it's implemented across the board (in a lot of frameworks).

    Sure the Active Record could contain business logic, that isn't the argument that I see being put across, rather that the business logic is accessible from the Controller, rather than a Model.

    I've seen that a lot as well with Zend Framework in how it's used. The argument therefore, therefore is that the ORM isn't encapsulated within a given Model, and that the ORM is used directly from a Controller.

    That in effect, does break the separation that MVC purports to support.

    > Rails, however, being a shiny object unto itself, has attracted masses of
    > otherwise clueless web construction workers and subdued their minds.

    I would agree with that as well, as in effect, it's the same thing that happened when the shift started towards PHP for a lot of people who were never from a programming background.

    Those people had little understanding of programming methodologies, etc and they made mistakes, however in saying that, now matters have matured more or less; People are still making mistakes, but not to the same extent.

    Or maybe... Using a framework, which is more common today, they just don't get the opportunity to make those mistakes?

  11. #36
    SitePoint Addict
    Join Date
    Sep 2006
    Posts
    232
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I agree with Kore, the author or Why ActiveRecord Sucks. I left a message a couple of months ago about why it doesn't work in PHP. And I also believe that some frameworks got it wrong. We shouldn't port ActiveRecord to PHP, like Kore said, it sucks. And this guy knows exactly what he's talking about (I also like his post about why BBCode is a mistake). I also left a message about ORM, another mistake aim to hide relational databases atrocities.

  12. #37
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I found this article as well:

    http://kore-nordmann.de/blog/why_act...ord_sucks.html

    It goes more indepth about it.

    Basicly with AR or ORM you are sacrificing flexibility for simplicity.

    People seem to adhering AR or ORM principle's blindly thinking its a better solution.

  13. #38
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston View Post
    > ... you're saying the application should have only simple select statements, which
    > obtains the (complex) data from a view?

    From what I understand of Views in database relational management, yes is the answer to your question. I don't use these tools personally, as I believe that, that given complexity should remain with the application but I can understand why some would use it [Views].

    I could say it's personal preference but it's not, as there are some advantages I suppose? You just need to weigh them up against the disadvantages, which of course would be dependent on the application you have in mind.
    The problem is that relational databases were originally intended not as a simple data dumping tool as most people tend to use them today; this tendency is especially noticeable in the fields where actual needs for data storage are very simple, like Web development (e.g. even the simple CMS's tend to use MySQL when a simple flat-file based system would suffice, as Dikuwiki perfectly proves). The data in real world tends to be very complex -- if you have ever worked on, say, banking software, you'll know what I mean -- and RDBMS's have developed to support this complexity.

    Essentialy, relational databases were invented to help distribution of concerns in software, providing a place to hold all kinds of data. Advanced features like views and triggers weren't introduced for fun or because developers thought they might be useful, but precisely because they proven necessary. You need to imagine a complex IT system, where the database is a central place which contains all the important data, and there might be a lot of different applications accessing and working with this data.

    In a banking application I worked at, a business transaction essentially came down to adding and changing a lot of information on a number of locations throughout the database. If this functionality was left to different applications -- and there were several, from branch office with DOS front-end, to Internet banking application written in Net.Data (don't ask) to automated timed transactions written in C -- then each time a procedure changed we would have had to change all those applications. Using stored procedures, views and triggers we were able to simplify everything greatly, as those applications only behaved as entry points, providing input data and presenting results, while the data crunching and juggling has all been done in the DB.

    I know that -- especially in the Web development world -- it is not always economical to have a dedicated DBA expert, but if you have any kind of integration with some other applications, or even if you provide several different entry points to your data, it might be prudent to transfer most of your data-related code inside the application itself. Some databases are better suited to this than others, but all of the "big three" RDBMS's (Oracle, IBM DB2, Microsoft SQL Server) have all the necessary tools and have support for numbers of languages in their stored procedures. PostgreSQL is also known for wide support of procedural languages: the standard distribution includes PL/pgSQL, PL/Tcl, PL/Perl, and PL/Python, while the PgFoundry lists a number of additional ones, including PL/Java, PL/ and even PL/LOLCODE; and of course there is PL/php.

  14. #39
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, I agree with you wholeheartedly in what you are saying about the complexity of the application, but you've said as much as to where I was coming from in my previous post in regards to web development?

    You don't see that particular level of complexity in most of todays web applications, in that you need to (are forced?) put that application level logic in the database. I don't use Views myself, and I've never had a use for Triggers either, but that's not to say they're not important, as in some cases they are,

    > which of course would be dependent on the application you have in mind.

    As to your other statement that databases are being abused I am aware of that as well, where the data in question would be better suited on a file system. I'm not in disagreement with you, nor am I saying not to use Views, et al but that there are specific times and places for them, rather than just to solve a problem in the application it's self where the problem is technical, and nothing to do with complexity in that given context.

  15. #40
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My ideal approach is "the best suited tool for each situation". Unfortunately, in reality we have too many simple Web applications which unnecessarily use databases, and I have to adjust to that reality.

    Another point here is to think ahead instead of just solving this moment's issues. The best way for that is to separate the concerns; many bytes have been used about the separation of business and presentation logic, but people tend to forget that there is such a thing as data logic, which best fits into a layer of its own.

  16. #41
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think I'm getting the hang of it!

    Please correct me if I'm worng about these statements:

    Models: Use them for all data retrieval/storage operations, keep the return result as generic as possible. Arrays of raw (or slightly cleansed) data work well as return types fron model functions.

    Don’t limit your thinking with models to just database operations. Any data storages/retrieval operation is a candidate for a model. Use them to wrap web service API’s, and other sources of data as well.

  17. #42
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by blueyon View Post
    I think I'm getting the hang of it!

    Please correct me if I'm worng about these statements:

    Models: Use them for all data retrieval/storage operations, keep the return result as generic as possible. Arrays of raw (or slightly cleansed) data work well as return types fron model functions.

    Donít limit your thinking with models to just database operations. Any data storages/retrieval operation is a candidate for a model. Use them to wrap web service APIís, and other sources of data as well.
    Models don't just retrieve data, models ARE your data, plus the logic that gives meaning to the data. An object that simply retrieves generic data is pretty much just a database abstraction layer.

  18. #43
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Arrays of raw (or slightly cleansed) data work well as return types from model functions.

    Arrays? Query functions return results (as resource). If you convert them into arrays, you need to traverse this raw array for the second time to get formatted output.

    IMHO is better pass directly results, although you have to write formatting objects for each type of db separately.

  19. #44
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees View Post
    Models don't just retrieve data, models ARE your data, plus the logic that gives meaning to the data. An object that simply retrieves generic data is pretty much just a database abstraction layer.
    I use the term generic data because it makes the models more reusable. If the models are used on more than one page and different pages require different formatting of data.

    Maybe one page requires you include a price formatted and another requires unformatted so is can add taxes etc..

    Please advise how you do these sort of things?

    Please post some examples.

  20. #45
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by blueyon View Post
    I use the term generic data because it makes the models more reusable.
    Well, parts of the model layer can be generic, but since the model layer includes business logic there's necessarily a fair amount of application specific code.

    Quote Originally Posted by blueyon View Post
    If the models are used on more than one page and different pages require different formatting of data.

    Maybe one page requires you include a price formatted and another requires unformatted so is can add taxes etc..
    What exactly do you mean by formatted? If it's "$200" vs 200, that distinction is made by the view, not the model.

  21. #46
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees View Post
    Well, parts of the model layer can be generic, but since the model layer includes business logic there's necessarily a fair amount of application specific code.



    What exactly do you mean by formatted? If it's "$200" vs 200, that distinction is made by the view, not the model.
    Ok what do you mean by model layer includes business logic?

    Do you mean:

    PHP Code:
    <?php
    class ModelProduct extends Model {
        function 
    getLatestProducts($limit 6) {
        
        }
        
        function 
    getProductsInCategory($category_id 0$language_id$start 1$limit 20) {
            
    $category_info $this->database->getRow("select distinct name from category c left join category_description cd on (c.category_id = cd.category_id) where c.category_id = '" . (int)((!$this->request->get('path')) ? '0' : (int)end(explode('_'$this->request->get('path')))) . "' and cd.language_id = '" . (int)$this->language->getId() . "'");
        }
        
        function 
    countProductsInCategory($category_id 0) {
            
    $result $this->database->query("select count(*) as total from product_to_category p2c left join product p on p2c.product_id = p.product_id where p.status = '1' and p2c.category_id = '" . (int)$category_id "'");
        
            return 
    $result->get('total');
        }
            
        function 
    getProduct($product_id$language_id) {
        }
        
        function 
    getOptions($product_id$language_id) {
        
        }
        
        function 
    getImages($product_id$language_id) {
        
        }
        
        function 
    getDiscounts() {
        
        }
    }
    ?>
    I seem to do the bulk of my code in the controller and have a library of classes that is stored in the registry.

    The registry is passed into the controller and models are called to get data from the database or any other external source. The data is then maniplulated in the controller and is then fed into the view.

    Is this correct? I know most of the frameworks such as Code Igniter work this way.
    Last edited by blueyon; Nov 6, 2007 at 17:34.

  22. #47
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Another question.

    I don't like putting the objects in the view. I have a currency class that correctly formats the price.

    Are you still saying I should put the object in the view?

    Should it be handled in the controller if its an object that formats the price?

  23. #48
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by blueyon View Post
    Ok what do you mean by model layer includes business logic?
    I don't know of any formal definitions of for business logic, but it's basically the logic that interacts with your data. If you're talking about products, they have properties like price, description, etc. as well as methods that interact with those properties, like increasing inventory. It also includes things like systems for calculating taxes, which involves objects that represent inventory items, tax rates, and people's addresses. The controller ideally is limited to handling the flow of data from the user to the models, and from the models to the views.

  24. #49
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think I'm getting the hang of this now!

    How to know what classes to put in your library and which ones to use as models?

    I know all the framework type classes will be in the library.

    What about a classes like shopping cart, taxes, currencies etc..

  25. #50
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by blueyon View Post
    I think I'm getting the hang of this now!

    How to know what classes to put in your library and which ones to use as models?

    I know all the framework type classes will be in the library.

    What about a classes like shopping cart, taxes, currencies etc..
    You could simply have a section in your library for models that you know you will reuse? Just because it's in the library, doesn't mean it's not a model anymore.


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
  •