SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 27

Hybrid View

  1. #1
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)

    Most ORMs are overkill...

    I am entirely open to debate on this, but in my opinion systems like Doctrine are incredible overkill for what they do, and some of the things they do are just plain pointless (Criteria objects, anyone?)


    The problem with a lot of ORMs is that to create a model for a single table, they force you to model the table in PHP with at minimum the table structure and in some cases data relationships.


    This information is stored in the database? Why should my application be doing the same checks the database does?
    There is no need. Let the database do its job.
    It can do it far more efficiently than a PHP script can. The database will helpfully report and problems back to the application so checks at this stage are not required.


    There are 2 main problems with this:
    1) Although this can be avoided by scripts which generate the model, the model needs to be written to include most of the table metadata

    2) it's unnecessary load on the server. The model is now doing several extra tasks:
    -Loading the metadata.
    -Data Validation. As I mentioned previously the same checks which are later going to be done by the database


    Dont even get me started on the pointlessness and even hindrance of "Criteria Objects". There is nothing wrong with having SQL as a string in your code for non CRUD queries.

    The idea of an ORM is good, and I wrote a basic ORM class in 125 lines and it works fine for one to one and one to many relationships and using a container class I see no reason that many to many couldn't work.

    Can anyone enlighten me to the logic behind systems such as Doctrine and Propel, and why they're used?

  2. #2
    SitePoint Member
    Join Date
    May 2006
    Location
    Russia, Komsomolsk-on-Amur
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Share your implementation, please :-)

  3. #3
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    The problem with a lot of ORMs is that to create a model for a single table, they force you to model the table in PHP with at minimum the table structure and in some cases data relationships. This information is stored in the database?
    You're assuming that 1 table = 1 class. I agree, if that's the case for all of your domain objects, an ORM is overkill. But a complex domain model diverges significantly from the table schema, and thus you need something to handle that complexity.

    Quote Originally Posted by TomB View Post
    Why should my application be doing the same checks the database does? There is no need. Let the database do its job.
    I assume you're talking about validation? A big thing for me is user feedback. I want to give the user the most helpful information I can, and that often means checks that differ from just whether or not a record can be inserted. Personally, I don't find db errors to be all that informative; definitely not something I could display to the user, and too coarse-grained to parse in order to give the kind of feedback I need to give.

    Quote Originally Posted by TomB View Post
    Dont even get me started on the pointlessness and even hindrance of "Criteria Objects". There is nothing wrong with having SQL as a string in your code for non CRUD queries.
    In general, I agree with you. Criteria objects seem rather wordy. However, sometimes being database-agnostic is useful, and a system that generates db-specific SQL for you is helpful. Also, at a certain point of complexity you're going to have to do a lot of string manipulation in order to get the dynamic queries you need. An object syntax can make this easier, so you can worry more about data aand less about syntax.

    Quote Originally Posted by TomB View Post
    The idea of an ORM is good, and I wrote a basic ORM class in 125 lines and it works fine for one to one and one to many relationships and using a container class I see no reason that many to many couldn't work. Can anyone enlighten me to the logic behind systems such as Doctrine and Propel, and why they're used?
    I would argue that what you wrote is not an Object-Relational Mapper, as it does not technically 'map' between objects and a relational database. However, I am assuming the word 'map' implies a difference between the two. If your objects fit 1:1 to tables in the database, it is fairly simple to autogenerate from a table name (as you said, 125 lines). I would prefer to call ActiveRecord a datasource, or some derivation of a 'data access' class, etc. But not an ORM.

    Rails made ActiveRecord popular because it's simple and easy to get up and running. It basically gives an object oriented interface to your database schema. However, it becomes less useful as your domain logic increases in complexity, and more complex patterns (like DataMapper) start to become useful. However, I can definitely see where you (and the Rails crowd) are coming from, as many websites have minimal domain logic and are more data-driven. That's where AR shines.
    Last edited by allspiritseve; Jun 17, 2009 at 07:01. Reason: Spelled 'coarse' wrong... perfectionist here :)

  4. #4
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't know much about Propel - I have a personal dislike for it - but use Doctrine and consider it to be the best thing PHP has to offer.
    Quote Originally Posted by TomB View Post
    1) Although this can be avoided by scripts which generate the model, the model needs to be written to include most of the table metadata
    I see it the other way around. I have really no use for the data or how it's represented in the database. What I want to do is handle objects that provide me with my data in my application, preserve their identity through complex queries and so on. This is also why I'm perfectly content with setting up my record classes in Doctrine, either in code or through configuration (YAML is the preferred way for me so far). Oh, doctrine build-all-reload, how I love thee.
    -Loading the metadata.
    The trouble is, the database does not actually have the data required for an ORM to operate. The relations and how they are mapped to objects are not in fact well-defined. This is why it is necessary to provide the metadata in some form or another if you wish to implement and use an object relationship mapper.
    -Data Validation. As I mentioned previously the same checks which are later going to be done by the database
    This point was summed up nicely above.
    Dont even get me started on the pointlessness and even hindrance of "Criteria Objects". There is nothing wrong with having SQL as a string in your code for non CRUD queries.
    Programmatical generation of queries through specific query objects built for that purpose is a useful thing to have, whether you're on an ORM or not. See Zend_Db_Select for another, DBAL-independent solution, although I would consider Doctrine's the most refined one by far. I'm perfectly fine with plaintext SQL or OQL strings in the code, but Query objects achieve a level of composability and flexibility unattainable otherwise.
    The idea of an ORM is good, and I wrote a basic ORM class in 125 lines and it works fine for one to one and one to many relationships and using a container class I see no reason that many to many couldn't work.
    I very much doubt you're doing most of the things an ORM is supposed to solve in 125 lines.
    Can anyone enlighten me to the logic behind systems such as Doctrine and Propel, and why they're used?
    I love the level of abstraction, convenience and unhindered development Doctrine provides me with.

  5. #5
    SitePoint Member romanb's Avatar
    Join Date
    May 2006
    Location
    Berlin
    Posts
    22
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Since you posted this in a PHP-related forum do you mean only PHP ORMs? If so, why do you consider these overkill and comparable tools in other languages not? (Hibernate, EclipseLink, iBATIS, SQLAlchemy, etc.).

    Your post indicates to me that you're not really familar with the basic ideas and totally different approaches of ORM (i.e. ActiveRecord <-> Data Mapper), which is no problem but I'm really wondering how you come to a conclusion like "Most ORMs are overkill" without a broad knowledge of ORM technology.

    Did you want to say something along the lines of: "From where I stand and what I need for my daily work, most ORMs seem to be overkill..." ?

  6. #6
    SitePoint Member
    Join Date
    May 2009
    Posts
    6
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ORMs are good for only one thing, saving your models to the database and retrieving your models from the database for display on a single page.

    Once you start using them for other things like generating lists of objects, pagination then you start hitting issues. Infact here you are better off using straight SQL and PDO to return an array of data that you format into HTML for display.

    ORMs should be used for instances where they are good for, and leave the rest lean and mean

  7. #7
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ssmusoke View Post
    Once you start using them for other things like generating lists of objects, pagination then you start hitting issues. Infact here you are better off using straight SQL and PDO to return an array of data that you format into HTML for display.

    ORMs should be used for instances where they are good for, and leave the rest lean and mean
    Technically an ORM doesn't really have anything to do with generating lists or pagination. What you do with the objects once you get them is your business. There's no reason you can't do Pagination and lists with objects.

  8. #8
    SitePoint Member
    Join Date
    May 2009
    Posts
    6
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ORMs are good for only one thing, saving your models to the database and retrieving your models from the database for display on a single page.

    Once you start using them for other things like generating lists of objects, pagination then you start hitting issues. Infact here you are better off using straight SQL and PDO to return an array of data that you format into HTML for display.

    ORMs should be used for instances where they are good for, and leave the rest lean and mean

  9. #9
    SitePoint Guru
    Join Date
    Jun 2006
    Posts
    638
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ssmusoke View Post
    ORMs are good for only one thing, saving your models to the database and retrieving your models from the database for display on a single page.

    Once you start using them for other things like generating lists of objects, pagination then you start hitting issues. Infact here you are better off using straight SQL and PDO to return an array of data that you format into HTML for display.

    ORMs should be used for instances where they are good for, and leave the rest lean and mean
    That's not true.
    ORM objects can be used to:
    - simplify your code
    - centralize your data load/save code
    - centralized object cache

    For loading lists, you can do something like this (in my system):
    PHP Code:
    // Returns a list of items.
    $items Items::findWhere('condition = true'); 
    And your describing this problem:
    PHP Code:
    // Returns a list of items.
    $items Items::findWhere('condition = true');
    // Loop the items
    foreach ($item as $items) {
      
    // Data is a linked object, resulting in one SELECT per item in this loop
      
    $item->data->value++;

    That can be fixed like this (in my system):
    PHP Code:
    // Returns a list of items, and load all their 'Data' using a join..
    $items Items::findWhere('condition = true',Data);
    // Loop the items
    foreach ($item as $items) {
      
    // Data is a linked object, already there
      
    $item->data->value++;

    This will do 1 select, faster for most projects.

    That can also be fixed like this (in my system):
    PHP Code:
    // Returns a list of items, and load all their 'Data' using a join..
    $items Items::findWhere('condition = true');
    // Precache the linked Data objects
    Data::precacheLinked($items);
    // Loop the items
    foreach ($item as $items) {
      
    // Data is a linked object, already in the cache, so no selects are done.
      
    $item->data->value++;

    This will do 2 selects, and cache the data. I use this in systems where data can be cached, and where the 'Data' and 'Item' can be used by other HTTP requests without having to hit the database.

    But looking around the forum, I have to agree, 99% of the solutions provided here are WAY overkill, and WAY slower than they need to be.

    Search around for some of my posts on the subject, I posted quite a bt of information on how some of this can be achieved using a simple, lightweight ORM abstract class.

    Example, my ORM class can do pretty much everything you need to do (as long as your using simple and not composite primary keys), and it's all around 1500 lines of code. (That includes validation, db class, error classes and a few things like that.)

  10. #10
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Vali View Post
    I have to agree, 99&#37; of the solutions provided here are WAY overkill, and WAY slower than they need to be. Search around for some of my posts on the subject, I posted quite a bt of information on how some of this can be achieved using a simple, lightweight ORM abstract class... around 1500 lines of code.
    I'd normally just leave this, but I've been talking to some people who are confused by this post. An ORM like Doctrine or Propel may seem like overkill for many people, but that's because those people don't need an ORM. They need a simple datasource solution like ActiveRecord, which is what Vali is discusing above. ActiveRecord is not an ORM. For those of you who are curious, here's what Martin Fowler has to say on the subject (note he's using a DataMapper, which is a specific pattern that makes up a portion of what you might refer to as an ORM):

    Quote Originally Posted by Martin Fowler
    Active Record is a good choice for domain logic that isn't too complex, such as creates, reads, updates, and deletes. Derivations and validations based on a single record work well in this structure.
    In an initial design for a Domain Model the main choice is between ActiveRecord and Data Mapper. Active Record has the primary advantage of simplicity. It's easy to build Active Records, and they are easy to understand. Their primary problem is that they work well only if the Active Record object corresponds directly to the database tables: an isomorphic schema. If your business logic is complex, you'll soon want to use your object's direct relationships, collections, inheritance, and so forth. These don't map easily onto Active Record, and adding them piecemeal gets very messy. That's what will lead you to use Data Mapper instead.
    Another argument against Active Record is the fact that it couples the object design to the database design. This makes it more difficult to refactor either design as a project goes forward.
    Thus, when your objects start to deviate from your database schema, an ORM starts to become useful and is no longer overkill for your project.

  11. #11
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,048
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    There will never be a true separation between the domain and database because at the end of the day your dealing with single tables. No matter how or what you do everything is stored in separate tables. The ActiveRecord pattern is no more less adequate for "complicated" relationships than a mapper. Seems like an unjustified bias to me.
    The only code I hate more than my own is everyone else's.

  12. #12
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    There will never be a true separation between the domain and database because at the end of the day your dealing with single tables. No matter how or what you do everything is stored in separate tables. The ActiveRecord pattern is no more less adequate for "complicated" relationships than a mapper. Seems like an unjustified bias to me.
    The ORM provides the separation, so you are working with objects that are not even aware of tables. It's not impossible to have a true separation, just difficult. That's what the ORM is for, and it is far more adequate to do so than ActiveRecord.

  13. #13
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,048
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    It doesn't provide a true separation because even in systems like the phpDataMapper you still must define table information. By defining that information a true separation can't exist. In the end everything has to be related to the table in pure in SQL in some way.
    The only code I hate more than my own is everyone else's.

  14. #14
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    It doesn't provide a true separation because even in systems like the phpDataMapper you still must define table information. By defining that information a true separation can't exist. In the end everything has to be related to the table in pure in SQL in some way.
    The Data Mapper / ORM still knows about the database. That's their job, to translate between the layers. Your domain objects can be completely separated though.

  15. #15
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,048
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    So how does that make management of "complex" relationships more or less adequate than a ActiveRecord?

    Defining merged mappers doesn't seem very efficient based on each relationship. Seems like a pain if you ask me…

    class Blog {

    }

    class User {

    }

    class BlogUser {

    }

    class Post {

    }

    class UserBlogPost {

    }

    What a mess…
    The only code I hate more than my own is everyone else's.

  16. #16
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    So how does that make management of "complex" relationships more or less adequate than a ActiveRecord?
    In an Active Record, your object relationships ARE your table relationships. They have to be. Complex object relationships are not equal to table relationships though, sometimes differing significantly. Thus you need a translation layer to map between the [tables and their relationships] on one end, and the [objects and their relationships] on the other end.

    Quote Originally Posted by oddz View Post
    Defining merged mappers doesn't seem very efficient based on each relationship. Seems like a pain if you ask you…
    Are you talking about having [1 Mapper + 1 Domain Object] vs [1 Active Record]? I don't think it's a pain, personally. My Domain Objects end up being very clean and efficient with out all of that persistence logic, and my Mappers end up very clean and efficient because they don't have to worry about all that business logic. But again, it's probably overkill if your domain objects align 1:1 with your tables. In that case, you don't need DataMapper, you don't need an ORM, you need a simpler pattern like a Gateway or ActiveRecord. What most people miss (especially the Rails crowd, that everyone seems to want to mimic) is that no one datasource pattern is or can be perfect for every situation. ActiveRecord is great when you don't have much business logic (which is most websites) but after a certain point of complexity (ie most [web] applications) it is not the best tool for the job, and something better suited to handle that complexity is needed. Thus the statement 'Most ORMs are overkill" is incomplete, because it's overkill for some projects but almost a requirement for others.

  17. #17
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,048
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    I'm talking about if I need bring in users posts, blogs, threads, x,y,z.

    Placing that in a User mapper theoretically wouldn't be correct. The domain object there is actually represented by merging those together. Which would result in something like:

    PHP Code:
    UserPostBlogThreadZYZMapper {


    a hassle and mess

    rather then:

    PHP Code:
    $users User::find(array(
          
    'include'=>array('posts','threads','xs','ys','zs','blogs')
    )); 
    Keeping everything separate enables me to make that decision at run time without ANY additional merged mappers or data entity objects.
    The only code I hate more than my own is everyone else's.

  18. #18
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Who said anything about merged mappers? Mappers can handle relationships. In my ideal system I'd call this:

    PHP Code:
    $users $userMapper->findAll(); 

  19. #19
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,048
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    So what becomes the difference between that and say just getting the blogs, threads and posts?

    Unless your saying that will only find all the users and everything else will either separate queries when needed or accessed via a identity map?

    However, then the question becomes given 100 users where I need direct access to all those listed items that would amount to (number of users x 6 ) queries initially speaking.

    PHP Code:
    foreach($userMapper->findAll() as $user)) {
       
    $user->blogs// query
       
    $user->threads// query
       
    $user->posts // query
       
    $user->xs// query
       
    $user->ys// query
       
    $user->zs// query

    Give even 20 users that becomes a considerable amount of trips to the db initially wouldn't it?
    The only code I hate more than my own is everyone else's.

  20. #20
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz
    The domain object there is actually represented by merging those together.
    The combination of those is not a single domain object, but multiple domain objects that are related to each other. Putting them into a single object wouldn't make sense-- that's not at all representative of the domain. (A user isn't a post, nor a blog, nor a thread, etc.) Just because you might want them all at once, doesn't mean they are to be merged.

    Quote Originally Posted by oddz
    So what becomes the difference between that and say just getting the blogs, threads and posts?
    First of all, if you're arguing whether or not what you're doing can be done with a DataMapper, of course it can. One big difference, though, is a DataMapper is working with objects. Those objects may not align exactly with tables in the database, and may require a couple extra joins that you are not accounting for. That's not a fault of the DataMapper-- just a complex domain. Thus, specifying all of them in one query with your class would be a horrendous job. And then what if you have to call that query again in another script? You'd have to duplicate that huge complex, unwieldy query all over again.

    I would much rather specify defaults that I can override at runtime if necessary. For instance, in your example, I would set up my UserMapper to batch lazy load Posts. Thus, if I'm grabbing multiple users and then running them through a foreach, the first access on a User's associatied Posts collection would call a query to fetch all posts for all users originally requested. Each of these posts would probably have eager loaded comments and tags, and these objects would be ready to use. I'm sure you can imagine other related objects being lazy loaded at this point (and when they are loaded, others being lazy/eager/batch loaded, etc.) and all this can happen with that one line of code I showed you before. No work needed on your part. If my database were as simple as yours, I would get away with one query for each relation on my User object-- thus totalling 6 queries which is totally manageable.

    If I needed something different, I always have the option of writing a custom finder method in the mapper. There might even be an easy way to specify object graphs through a generic finder method-- but most of the time, default loading strategies are fine. They just need a little forethought, but save you tons of time in the long run.

  21. #21
    SitePoint Guru
    Join Date
    Jun 2006
    Posts
    638
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    oddz: I think your are a bit off.

    Let me explain:

    In website programming, you have a few layers.

    #1 One of them, is the 'ActiveRecord' layer (what 95% of the people call an ORM...).
    That contains no business logic what so ever.

    Example:
    - select/update/insert/delete data from the db/wherever your saving it.
    PHP Code:
    $user = new User(5);
    $user->name 'bob';
    $user->profile->description 'bla';
    $user->save();
    echo 
    'Age: ' $user->age// Results: 'Age: null' 
    The way your code deals with this 'ORM', is up to you. You can lazy load it (2 selects, 2 updates), don't lazy load it (1 select, 2 updates), use the cache (2 updates), etc. Up to you.

    BUT, the only thing this does is transfer your data to and from the database/data source. Notice that when you echo the 'Age' (not in the DB, since you saved the 'Date of Birth' there), you get nothing or 'null'.

    I like this part to be as simple and fast as possible (from development and production point of view). My data "models" are genrated automatically by my settup script (from the database table structure.)

    Also, this is where I see that most people over-complicate things. You should not need more than 1000 lines of code to do this (for the abstract class you always extend). My class has around 250 lines of code, and it also deals with validation.

    #2 Then you have the business logic.
    Here you put your system logic.
    Example:
    - when the user logs in, they also add a record in the UserLog
    PHP Code:
    // a) My favorite way of doing it, that can be used 99.9% of the time
    $loggedInUser User::login('name','pass');

    // b) A more OOP way
    $user = new User();
    $user->login('name','pass');

    echo 
    'Age: ' $user->age// Results: 'Age: 9'
    echo 'DOB: ' $user->dateOfBirth// Results: 'Age: 2000-06-18'

    // Change the age
    $user->age 29;

    echo 
    'Age: ' $user->age// Results: 'Age: 19'
    echo 'DOB: ' $user->dateOfBirth// Results: 'Age: 1990-06-18' 
    Now, your using an 'ORM'. The 'Age' field is not in your DB/data source, but only in your Object, (Object-relational mapping).
    This object also has some business logic to it (might want it here or in another layer...). This logic is to "add a log entry every time the user logs in, and store the user in the session, so it can be loaded via $loggedInUser = User::getLoggedInUser();.

    Version b) is "better", since you can have a user with some data (not in the DB) set to it, that can be logged in (set some other flags to that object). Version a) on the other hand, always returns a new object (I use it since I never set those flags like that).


    Under most circumstances (in websites), all you need is #1, with very minimal #2 (like age...).

    Once your project matures, and you end up using caching for some of your persistent data (to compliment the DB), you will be using ORM more and more.

    Hope this helps.

  22. #22
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Vali View Post
    #1 One of them, is the 'ActiveRecord' layer (what 95% of the people call an ORM...)
    Correction: what 95% of the people incorrectly call an ORM.

  23. #23
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,048
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    ActiveRecord maps field names to objects – object-relational-mapper.
    The only code I hate more than my own is everyone else's.

  24. #24
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    ActiveRecord maps field names to objects – object-relational-mapper.
    Quote Originally Posted by Martin Fowler
    Active Record... couples the object design to the database design.
    Having the object design coupled to the database design defeats the whole purpose of an ORM: to map between the layers so that neither depends on the other and they can evolve separately.

    The reason so many people think ActiveRecord is an ORM is because Rails calls their AR implementation an ORM. That shouldn't be a big problem, except it leads to people comparing ActiveRecord and something like Doctrine and concluding "Most ORMs are overkill...". That makes it harder for people to understand when an ORM is necessary, and makes it harder for those trying to develop ORM solutions to handle complex domains to get any feedback among posts like "I made a 100 line ORM, what's all the fuss about?". I know the Doctrine developers are currently struggling to get enough contributors, and I suspect the fact that everyone thinks ActiveRecord is an ORM has a lot to do with that.

    Another thing people seem to forget is that ActiveRecord should be a tool in your toolbox, not the only way to persist data. Ideally, frameworks should have a couple persistence patterns implemented, probably either AR or Table Data Gateway for simpler stuff, and something that has some basic mapping capabilities. That way, people can choose what they need based on the level of complexity in their Domain.

  25. #25
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,048
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Your right in the sense it depends what your needs are. However, I will argue that when implemented in a non 100 line manor either can be equally effective. I haven't come across any data to suggest otherwise.
    The only code I hate more than my own is everyone else's.


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
  •