Thanks for your responses. I am really choosing a framework that will get three programmers collaborating on a very simple OOP project.
It is a simple booking app. Students book equipment, kits (groups of equipment), rooms or a special room (a gallery) So >However, unless you are building very simple administration screens I guess there will be simple admin screens (except for the booking view, unless it is just an admin CRUD for a lookup table) But, the remarks about realestateAgent->house being a problem have put me off the Ruby-Clone idea. Date: Wed, 21 May 2008 17:02:33 -0400 From: [EMAIL PROTECTED] To: [email protected] Subject: [CFCDEV] Re: cfwheels +1 Also in my environment I have no control over my database so even when it MIGHT make sense I favor descriptive property names over matching. Our standard is vertical and horizontal consistency through the layers and objects of your application code. Persistence be damned; its a means to an end not the beginning :) Adam Haskell On Wed, May 21, 2008 at 12:28 PM, Dan Wilson <[EMAIL PROTECTED]> wrote: I responded to the Original posting on the Transfer list. Since it seems there is more activity here, I'll repost. I need an opinion on the whole idea of model components that are named after a table and have properties that exactly match the tables column names? It can be a good idea if your business objects exactly relate to your database tables. This can mean a lot less code to write! However, unless you are building very simple administration screens, this is pretty much never the case. A relational database is the best, optimized way to store and retrieve information. Proper database design relies on 3rd normal form, among other things, to guide the structure and contents of each database table. A business object, on the other hand, really has nothing to do with database structure or normalized forms of any kind. Business objects really are self contained structures that contain logic and data that represent the Proper Nouns in your application. Applications with objects modeled after true business objects are easier to maintain, understand and build. Applications with objects directly modeled on database tables are fragile, cumbersome and fail to scale in complexity. So, modeling your business objects as direct representations of your persistence tables, is a very poor idea indeed. DW _________________________________________________________________ Never miss another e-mail with Hotmail on your mobile. http://www.livelife.ninemsn.com.au/article.aspx?id=343869 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
