Classic chicken or egg first ,scenario. It's more likely the Data Models would be in place already. In which case what are the drawbacks when starting Object Modelling later? In the event that you are starting with Object Models first, you need to optimise the data at some stage after Data Modelling, which in turn may cause the Object Model to change. Any recommendations ? Are there tools that do the Data Modelling and optimisation automatically from Object Models ? The rules seem simple : 0,1,* associations, not to mention normalisation rules at least up to Third Normal Form. P.S. I mean data models for Relational Databases but any other types of databases would be useful to know. regards [ July 18, 2003: Message edited by: HS Thomas ]
This is a major subject for debate. My own experience at two things that worked well: Client server application, fat client. Did intricate object model first, connected to the database (and other stores) last. The client held lots of data in memory, manipulated it in kinda tricky ways and a good object model worked well. The object-to-storage mapping was mostly done by hand, which was expensive but stable enough that didn't kill us over time. Web application, thin client. Used the MS-DNA style with optimized data model first, a server object per table or view, a layer of objects above that that handle atomic operations, a layer above that that handle business operations made up of multiple atomic operations, then presentation. Because the server was stateless and did mostly simple transactions and IO, the object model was not critical. One thing you need either way is a good domain model. That is, without thinking about an object or database implementation, get an understanding of things in the real world and how they interact. From there you can go to either objects or database depending on the flavor of the application.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
This is real tricky. Good OO models are all about behaviour, good DB models are all about data. I've found that if you start with just one of the two its almost impossible to avoid ending up with a design skewed in favour of the initial model. I've found two approaches to help with deciding this. The first is to work out which of the two aspects (behaviour or data) is the most important to the customer(s). In some cases this is pretty easy - if you have to use a legacy DB, or the application has no storage of its own and only communicates by message passing to other apps, for example. The second approach is to do both types of design at once, in very small steps to make sure they are voth reasonable all the time.
To me going from object to data looks convenient. Please see my post here: http://dbforums.com/t816211.html where I have used a simple example to illustrate the point. Nalla
Joined: May 15, 2002
Wow! that's 5 different approaches,so far. Stans' based on in-memory storage requirements; Franks' based on data or application behaviour; Nalla's based on grouping user interactions and services; Keep them coming in. There must be more approaches. regards [ July 18, 2003: Message edited by: HS Thomas ]
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
It appears to me that my note is in line with Robert C. Martin's comment on the question. Nalla [ July 18, 2003: Message edited by: Nalla Senthilnathan ]
Joined: Jul 11, 2001
Originally posted by Nalla Senthilnathan: It appears to me that my note is in line with Robert C. Martin's comment on the question.
I understand him to favor a much more incremental approach, along the lines of: - start working on the first use case - write the classes you need to make it work - create the tables you need for this use case - do the same for the next use case - refactor both your classes and database tables so that they don't contain duplication (XPs Simple Design)
Joined: Jan 29, 2003
Interesting - That Martin post does seem to be suggesting an iterative approach, doing a few objects then enough data to support them in each iteration. In Agile Software Development he does a case study building a lot of running code with data provided by the unit tests themselves and no database at all, rather a different approach. I liked Frank's distinction between behavior focused apps and data focused apps. That's kinda where I was going, but not nearly so clearly. I was taking it from architectures - stateless web apps come up with different interactions than stateful fat clients - but trying to get the same place. Oops, forgot - Scott Ambler does a lot of work in this area. Here are a couple: Evolutionary Database Development Agile Database Techniques [ July 20, 2003: Message edited by: Stan James ]