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.
--- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com > -----Original Message----- > From: Jim Davis [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 13, 2003 11:50 PM > To: CF-Talk > Subject: Conceptual OO question(s) > > > Okay - I'm (finally) going to attempt to create a system using OO > principles. I've got (I think) a good understanding of OO concepts but > am having trouble converting my thinking. > > Specifically I'm having trouble defining for myself "touch points" > between the conceptual objects I'm creating and the database that will > store the data. > > As an example, I'm building a scheduling system for large, multi-venue, > multi-performer events for use on www.firstnight.org. I've designed my > data model (that, it seems, doesn't really change) and now want to > design my collaboration model. > > I'm sure that many of my questions are dense, but here's where I am. > Also I'm not having trouble programming any of this - I know I can do > all this, but I'm just not sure how to do it "right". ;^) I keep > finding myself leaning towards procedural code poorly contained in an > object wrapper. > > 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. I usually have a one to one ratio between business objects and service objects, although there are certain instance where there is only one service for a couple of very tightly bound business objects. If in doubt, separate the services. > 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. > 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. > 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. 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. > I hope some of this made sense... perhaps it will to me in the morning. > It's pretty late here. ;^) > > Thanks in advance, > > Jim Davis --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 9/1/2003 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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 Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
