lol. Great reply. :-) Thx Barney!
On 11/9/05, Barney Boisvert <[EMAIL PROTECTED]> wrote: > > Based on my experience building custom, app-specific generators, what > I've liked, disliked, and considered... > > A generator should be able to be rerun at arbitrary times and update > the CRUD part without affecting anything else. It should create beans > that have getters/setters for properties. It should allow custom > mappings between table names and entity names (i.e. I can say a table > called 'mytable' maps to an entity called 'TableDeMoi'). > > There should be some automated translation for underscore_separated > names to camelCase names, both for entities and fields. Surrogate > primary keys should always be translated to 'id' properties on > entities (i.e. person.person_id maps to Person.getId()). Both of > these should be optional/customizable if you're distributing. > > Methods should be smart enough to only do something when needed. So > if I load an entity and then immediately call save(), nothing should > happen, since the entity's properties haven't been changed. There > should be a 'save' method, which will intelligently insert or update, > ideally only the modified fields on updates. > > Beans should have a constructor that accepts full instance data as > args. Beans should automatically have basic validation coded by the > generator. I.e. INT fields can automatically check for integer-ness, > varchar fields can be checked for length restrictions, etc. That > should be easily extensible by the app developer, of course, without > affecting the ability to regenerate if the DB schema changes. > > Beans should have getMemento and setMemento methods that allow for > serializing the object state. According to the DP, the memento should > be opaque (usually an inner class), but CF doesn't afford that very > easily, so non-opaque is fine with me. Whatever that memento is, it > should be trivially serialized/deserialized, or some other means of > serializing/deserializing should be exposed. > > Some entity relationship support would be ideal, based on DB foreign > keys. I.e. if the 'car' table has an 'ownerId' field that references > person.id <http://person.id>, there should be getOwner:Person and > setOwner(Person):void > methods, and probably getOwnerId:int and setOwnerId(int):void methods > as well. Ideally the Person object would have getCarList, addCar, and > removeCar methods as well, but that's harder to autogenerate, unless > you're doing the whole schema at once, rather than a single > entity/table. > > And then the holy grail: many-to-many relationship support. I'd be > happy with forcing the 'link' table to be it's own implicit entity, as > long as the two 'real' entities are smart enough to have direct access > to the other 'real' entity. I.e. the link table entity is an exposed > implementation detail. For example, people own cars, cars are owned > by people. Person, Car, and CarOwnership entities with > Person.getCarList, Car.getOwnerList, and CarOwnership.getPerson > methods, along with their supporting methods. > > Updates to relationships need to be clearly documented, as does the > effect of calling save on an entity with modified related objects. > Propogation is good, but should be disable-able at some level or > another. > > I'd hope to see factory/managers for the beans so they're easy to use. > Aside from getPersonById, and getNewPerson, also have > createPerson(name, dob, ...), deletePerson(id), and updatePerson(id, > name, dob...) for calling from your UI(s). This would also be the > place for doing caching and lazy loading in an encapsulated way. If > you cache, hooks should be exposed that can be used for syncing across > a cluster (the sync stuff would be built by the app developer and > utilize the hooks). > > Some recognition of concurrency issues should be made, even if it's > just to explicitly say "you're on your own". Smart updates (i.e. only > updating modified fields) goes a long way to mitigating this issue, > but doesn't address it completely. For example UPDATE table SET f = f > + 1 WHERE id = 3; is atomic, but t=getTById(3);t.setF(t.getF() + > 1);t.save(); is not atomic. Concurrency issues don't exist with the > former, but do with the latter, unless the whole thing is in a > transaction. That's a restriction this type of code can't enforce, > but a well designed application will likely exhibit that behaviour so > if clearly documented, I'd say it's reasonable to assume. > > Of course, there are sound arguments against this sort of thing at > all. It's a delecate balance between using a tool to help you do your > job, and relying on a tool because you can't really do your job. I'm > all for using them until you've got a sound reason not to, though. > > cheers, > barneyb > > On 11/8/05, John C. Bland II <[EMAIL PROTECTED]> wrote: > > What is it "everyone" looks for in a CRUD generator? I see some folks > saying > > they'd like to see best practices, some want getters/setters, and others > > just want a function you pass everything too. > > > > Just a little reserach... > > > > -- > > John C. Bland II > > "I do what I can do when I can do it." - Chris Tucker, Money Talks > > > > -- > Barney Boisvert > [EMAIL PROTECTED] > 360.319.6145 > http://www.barneyb.com/ > > Got Gmail? I have 100 invites. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:223653 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
