> responses inline below. Keep in mind this is how I usually do things; > there > are many correct solutions, though all will share many of the same traits.
After I wrote this I finally found the "right" term for this: apparently they're called "Implementation Classes" (as opposed to the more real-world "Domain classes"). I'm not sure if that terminology is cardinal, but it has helped me search better. It's amazing how much easier it is to find things when you know what they're called. ;^) > > Consider that I have an "Artist" object which has properties like > > "name", "profile", "website", etc. That data is, of course, stored in a > > database (SQL Server, for what it's worth) table. Here are some of my > > confusions: > > > > 1) How do you (using good OO practices) put the data in the database? > > Does the "Artist" object have a "SaveData()" method (or somesuch) so > > that you first instantiate the object, then store the data in the > > database or do you have another object that stores the data for later? > > Everything I read talks about instantiating the object with data but > > nothing details the link between the persistent data store and the > > transient object. > > Your actual Artist object should know nothing about persistant storage, be > it a database, flat files, whatever. The object that instantiates the > Artist object should deal with the persistance layer. I typically call > such > objects Services, and they have methods like getArtistById() which takes a > numeric ID parameter, and returns an Artist object. That Service object > (in > this case named ArtistService) is the only object that knows anything > about > persisting Artists. Sounds good to me... I like the concept. I also like the abstraction in the sense that (it should) allow for easier migration to different persistence datastores. So my application is, if I understand this correctly, "layered". One layer does nothing but abstract the data. I actually already do this in my procedural programming - all data comes from a "Data Translation Layer" (DTL) and converts database data, for example, into useful data for the UI. The data translation layer is called by a "show" or "display" template that did nothing but display the data. For example "Artist-Show.cfm" would contain the layout and such and call "Artist-DTL.cfm" which would query the DB and format the "raw" data for the screen. I'm not sure if my procedural programming was OO-like or if OO just isn't all that different but at least I'm not spending MOST of my time confused... just some. ;^) > > 2) In the same way, when I'm editing the properties of the object does > > the object normally update the persistent store immediately in the > > "set()" methods or is there normally a method to do this all in one go - > > something like a "save()" method? > > This should also happen in the service object. I usually use > persistArtist() method, which takes an Artist object and stores it in the > database. It will chekc the Artist object's getId() method and if it > returns a valid ID, then the service knows it needs to do an update. If > it > returns an invalid ID, that means the object has not been persisted, and > needs to be inserted. Sound like my existing DTLs again - which is good. I'm a little unclear on the "trigger" here tho'. When you've got an "update" page and changes are made. Upon submit (assuming you want to store the data immediately) do first call the Artist object which, noticing a change, calls the persistArtist() method or do you call the service directly and have it, having noticed that it's changing the data, automatically update the Artist? The former seems to more sense to me (especially if you want to hold off making permanent changes until requested). I suppose that this is probably less of a best practices question and more of a "however it makes sense to the app" question, uh? > > 3) When I present a list of the artists do I (again using best > > practices) instantiate a structure (or array or whatever) of "Artist" > > objects (which will contain much more data than my list needs but seems > > conceptually sound) or do I have some intermediate "ArtistList" object > > which just outputs a record set? > > It's kind of personal preference. For large report-type datasets, I > usually > prefer to do a task-specific query (via a method in a service object, > though > not necessarily one bound to a business object type), and return that > recordset directly to the display. However if I have an admin page that > provides a list of users, I'll probably return a List of User objects. > List > is an object similar to Java's ArrayList which is just an object wrapper > around an array, but carries the benefit of being able to extend it with a > different underlying mechanism if that's more appropriate for the specific > data storage need. Are you saying that "List" is a generic object (an "Interface", right)? So then I would extend it to create (perhaps) "ArtistList", "VenueList" and so forth? One thought I had was that some of the "List" functions should (maybe) be handled by the overall container object (in this case "Festival") so that the Festival object would have "EventList()" and "VenueList()" methods returning arrays of objects. Perhaps also having methods like "SimpleEventList()" and "SimpleVenueList()" that just return simple recordsets? Sound sound? > > Basically this last one concerns memory usage. I can conceptualize a > > "Festival" object which contains many "Event" and "Venue" objects which > > are linked together by "TimeSlot" objects. The "Event" objects would > > further contain references to "Artist" objects which in turn contain > > references to "Asset" objects (images, multimedia, etc). > > > > Although I can conceptualize how the whole thing, all together, would > > "feel" and be constructed I'm having trouble conceptualizing how to pull > > just the needed information from the database. When an end user > > requests a list of Venues, then selects one to see the events at that > > venue what gets instantiated? > > > > Is it a "VenueList" object or an array of (all) Venue objects? > > Keep in mind that a good object model will let you make an insane amount > of > object caching. Your services and business objects should allow for > multithreading, so that they can be used my multiple clients at the same > time. If so, you can cache all the business objects in the service > objects, > which means instantion doesn't have to hit the persistance layer except > for > the first time. And because all the updates to the persistance layer also > happen through the service object, you can ensure that your in-memory > cache > is in sync with the persistance layer, so even across updates, you don't > have to run SELECTs. For this particular application this is exactly what I'm planning. The total amount of data is quite small (about 70 Venues and 200 Artists for a big one-day event). I plan to cache the entire model in memory for performance sake (this site gets a LOT of traffic on New Year's Eve). However I'm still a little confused how I would deal with really large datasets (the database we use at the office is several gigabytes in size for example - nearly 6 million products and a million-ish customers)... but I suppose that will come. > This also has a very nice benefit when you're building your application. > You can just skip writing any of the peristance code, and just let the > service manage the in-memory cache, and have a fully functional > application > without a database at all. Of course, the data won't survive a restart, > but > it lets you build the entire application without having to deal with the > persistance model until the end, which is a VERY nice feature. This is actually my problem - this is how all the books I've read pose things: as if there is an effectively infinite amount of space for these object models to float around in. For example one of the early classes I took modeled a Video Store - with "Tape" objects. It worked of course - but immediately places all the tapes into an array in memory - all 20 or so of them. The class, unfortunately, never really explained how this would work with 10,000 tapes. ;^) I know it DOES work somehow - but it's that leap from limitless theory to cold reality that I'm having trouble with. Thanks for the help. I'm still open to suggestions, but you've given me an (I think) a good path to follow. Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
