This just doesn't sound right.... 1

[jfrost10]

Hey guys,

MAJOR battle right now between a co-worker and myself regarding how we should continue with our modeling. She has no uml experience, and comes from a VERY HEAVY Data-centered development environment.

Anyway, she thinks that we should take all of the parent/child relationships that we have (as well as helper class relationships) and just make one big object that gathers all of those parameters so that we only make one hit to the database. Now, I'm thinking this is going to break a heck of alot of modeling rules (ie cohesion, loosly coupling, etc.).

Problem is that our boss is thinking its a hot idea. But it just doesn't seem right (why bother with objects at all, why not just grab recordsets then?!)

Can someone tell me if I'm wrong here? And if I'm not, any clear reasons I can pass on as to why this way wouldn't work?

Thanks guys,

Jack

 

[mikewoodhouse]

But it would work. (Sorry, I know that's not what you want to see!). And you're not wrong and neither is your co-worker. Helpful, eh?

It all depends on what the project's priorities are and what your best guess is about what happens after.

For example (heretic hat on) relational databases are slow and cumbersome. If, that is, you fully understand your data and know for certain that your schema and retrieval requirements are never going to change.

Loading all your data as one kinda denormalised recordset was a typical way to go about batch or reporting style tasks, say 10 years ago. And maybe still is for all I know, I just haven't been there for a good while.

Going multi-object in the way you describe is going to prove beneficial for any of the folowing reasons: (a) you want to be multi-tier (b) the data-based objects are likely to be resuable elesewhere (c) you expect the application to change over time (d) the app will have to support several significantly different transactions.

The thing is, good software got developed before there was OO or n-tier development. Heck, good software got developed before there were compilers. Perhaps in the end there are only good developers and "modern" techniques just make it easier for more of us to be good.

Do either of you understand the other's approach and its strengths and weaknesses? Until you both do then I suggest that you're in for a "religious" war, and no-one ever wins those...

My two pence-worth, anyway...

Mike

 

[OGHS]

I think the problem of doing this is to mean nothing with that "super-class" information (attributes); in other words its like say "pears and apples are the same thing". For sure it will look more like a proccess than like a class, but it could work anyway... Also I think this could drive you onto getting confused of what information you really need for making some operation, or just modifying or showing it.

I would say the main advantage of object modeling is the ease mannagement of information. This is very useful if you are planning to make something different than show, modify, delete or update that information or also if you are just planning to do this; you will always know what are you talking about!.

 

[jfrost10]

Thanks for your responses guys.
Mike: heh, you hit it with the "religious war" comment. Our meeting room has been like the West Bank Part 2 lately.

My main issue is really management and reusability, while hers revolves around extra hits to the database (she's not OO-intructed in any way). We have a set of "base" classes, and the idea would be that the "superclasses" we'd create would be combinations of those. However, OGHS brings up a good point about management: if one of the base classes change, and 10 of the supers are based on it, then all 10 need to be changed. And we have to KNOW that they need to be changed. So I see that it could work, but the overhead just seems to be so much greater.

These DBA people...always thinking their the cornerstone.


Thanks again,

Jack

 

[rac2]

What if someday you start getting data from XML documents in addition to the relational database? Or, maybe someone will say, "Take those emails from Outlook and put them into our application." Won't that pretty much blow up the data model that assumed your implementation was all in a relational database?

 

[jfrost10]

Hey guys,

Just wanted to let you know what we came up with to solve our little problem.

We're going to try and use composite objects to hold the other ones (so really adding another level of abstraction to our logic tier). This way, we can keep the objects we have, and the ones we create are only containers for them, so I think we're all happy with the idea...heh, so far.


rac: the beauty of our data model is that its really based on our state/class diagram for our entire system. So whetehr the data is stored in xml or in a file, they'll still be modeled in the diagrams and will fit seamlessly into our system.

Jack

 

[DonQuichote]

If you read the book "antipatterns", the really big alldoing class is called a God-class. It is very hard to maintain and even harder to write unit tests for.

 

[DonQuichote]

Sorry to follow up on my own post, but see:

http://www.antipatterns.com/briefing/sld024.htm

for extra information (the really big alldoing class is called a BLOB there)

 

[jfrost10]

Sweet, thanks for the link Don.



Jack

 

[DannyB]

Hi, You're absolutelly right jfrost, apart from killing the co-workers (lol), I'd suggest associating the responsability of the decision to the consequences.