A good question. I think we agree that both ways can work well... Usually, I do prefer the "less OO" style. In your example, a pure mapping class and business logic in a user manager.
The main reason is that what you call "OO style" seems to enforce a lot of arbitrary decisions. For example, when you bind an EMail object instance to a User object instance. Where to put the addXXX() method - into the User, or into the EMail ? (I see that ugly question appear repeatedly, e.g. in the language design. Do we want str.to_int() or Str.from_int() or int.to_str() ... etc...) Also notice that the "OO style" is not necessarily a pythonic style (which may also be desirable). Let's look out for examples: Python design prefers even to use a global len() function instead of str.len() etc. (hm, I don't like especially that case, but I think GvR also may have had its good considerations.) Or consider sqlalchemy-ORM where most functionality is in the orm-session. Other orms (SqlObject etc.) prefer to put methods into the mapped classes (i.e."Active Records"). The sqlalchemy design may also have other reasons (e.g.unit-of-work is wanted). But indepently from collecting actions in a unit-of-work, the design with methods in the session -not in the objects- feels well. (Sadly, this is more gut feeling than rational.) I think these design question is fundamental, and a lot of gurus already have written about OO for decades now. Should there really be no guru article, and no forum discussion about that ?? I'd also appreciate anyone showing me what knowledge already exists here. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
