On Mon, Feb 9, 2009 at 4:02 PM, Barney Boisvert wrote: > > On Mon, Feb 9, 2009 at 2:50 PM, denstar wrote: >> So do you guys think that the ActiveRecord debate is part of the "fat >> service" vs. "fat object" debate? > > No, not at all. Fat service (or it's equivalent inverse anemic domain > model) is about putting entity behaviour in your service layer. The > AR debate is where persistence operations should live. I.e. does it > make sense to ask a Person to find all people with from a given state, > or should you ask some sort of querying service that question. In > real life you'd certainly ask a person who their children are > (person.getChildren()). But you'd never ask a person for all the > subscribers with at least 10K in sales that live in Wisconsin > (person.findByIsSubscriberAndSalesGreaterThan10000AndStateIsWisconsin() > or whatever). Putting that latter behaviour on your Person class (via > a dynamic finder) really twists your domain model.
First, I agree, from the "modeling real world objects" perspective it doesn't make sense. However, that's one of the tenets of OO that I'm not sure is "where it's at", so to speak. The "real world" is so enormous (maybe endless), that until we've got some /way/ more powerful computers-- well, I don't know how successful modeling it will be. I'm not sure where that fits in, but I like to think about it. Domain specific languages are a good place to try to conform to real-world relationships, using a meta-language type deal. Eh. I agree tho, due to the super-duper-dynamical-nature of Groovy and CF, the lines are super-duper easy to blur. To some extent, these dynamic languages were actually designed to be this way, which is something we also shouldn't forget. Using something's strengths and all that. > The fact that that method is dynamically processed for you is great; > it's a huge benefit of using Grails. That said, the Person class is > NOT the place it belongs. With Groovy's neat dynamic programming, you > can easily "move" it to your DAO of choice which is handy, so you can > get back some of the purity without having to reengineer everything. > It's just in the wrong place to begin with. I'm starting to wonder if things that are "bad" in less dynamic languages aren't really so bad in more dynamic ones. It's hard to formulate/express, as I'm still working the idea, but... eh. NM, for now. >> Now, you can annotate your domain classes with this info, or use a >> Hibernate mapping file, neh? The mapping file keeps the ORM specific >> metadata out of your class itself, which is good for encapsulation, >> from one vantage point, but it's bad from encapsulation, from another >> vantage point, as you've got a couple places to change what is >> essentially related information. Sorta violates the single point of >> reference deal. > > I'm a fan of annotations, as thin as possible. It handles the base > cases quite well, but doesn't preclude the use of XML if some deployer > needs to do it that way. The Hibernate guys were on their game with > that one. And since your constraints and such are there in your > domain model (where they should be), it feels reasonable to supply > some additional annotations about the state semantics (this String is > short, this String is long, this date is transient, etc.) Hibernate is an interesting beast. Using the HBM mappings, you can pretty much model an entire app. I mean, you can do all kinds of crazy things. All, kinds. But you get into that problem, where you have to choose -- where is your model? You end up facing this problem so often, with all this cool stuff you can do (not at all limited to hibernate, I've run into it from many angles)... I finally decided that what really mattered, was the model itself. I think I mean what Peter says about it being the definitive artifact. It was the one thing that seemed to stay the same, no matter how I wanted to express things. It is "what will be", basically. > And yeah, modeling is kickass, though the tooling is still lagging. I > worked on a project that we did full roundtripping a couple years ago > and it was great, as long as you didn't need a scenario that the > tooling couldn't handle. Then you're stuck. ;) But that's > undoubtedly better now. JetBrains MPS stuff is interesting. Pretty steep initial curve, but I bet that line gets pretty long and flat at the top. EMF is getting pretty sick-- as in, wow can you do some cool stuff with it now (eRCP, etc.). Heck, Drools (business rule management system) has some pretty slick DSL making stuff, nifty tools, etc.. Yes, the modeling tools are really starting to "wow" me now. Maybe not 100% there, but holy crap, it's getting there. Probably where programming will end up, as... well, the *real* information isn't the code itself. Sorta. Unless you're doing Clojure. :-) Again, it should be noted that I really don't know what I'm talking about. I am having fun figuring it out, however. :) -- Silence is the sleep that nourishes wisdom. Francis Bacon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" 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/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
