Phillip,
 
I'm no expert, for sure. But to me, how to model certain relationships becomes much easier in the context of what the application needs to accomplish at a certain point in the application flow. Without that context, what you're left with is a model from what Alan Shalloway calls the conceptual perspective (Design Patterns Explained). Useful to begin to understand what you're dealing with, but you can't really build an application very easily from a conceptual perspective.
 
Yes, you could model the relationships between those entities conceptually - orders, customers, employees, vendors ... but when it comes to practically building your application, your model will probably be of little use to you. At any given moment in the application flow, you're probably not dealing with the grand relationship between orders, customers, employees, vendors, and security and whatever else you'd need to complete the picture. You're probably only dealing with those entities one or at the most two at a time. That you can model much more easily - and it'll work for you practically.
 
Specifically, to me, if i'm needing to display an order, in the ways you've outlined, i'd simply use an OrderGateway with functions like getCustomerOrders(myCustomerID), getVendorOrders(myVendorID). If i'm editing an order, well maybe i'd compose an Order object or an array of Order objects inside a Customer object IF i needed to. BUT i might not! Yes, a Customer has an Order on an conceptual level, but it might be sufficient to edit an order using only an Order object with a customerID.
 
Why? Because in that given moment, if i'm not editing any customer details, i might not really need the functionality that a Customer object gives me. No need to instantiated a Customer object if i'm not going to use it. Make sense?
 
In my opinion, i think us newbies are better off staying very practical in the beginning, firmly in what Shalloway calls the "implementation perspective". Stay very close to what you need to do in a given moment, and build your model from there. Once our experience grows, hopefully we'll be able to look ahead and around us and maybe model our app with an eye toward change.
 
Shalloway's book helped me a lot.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Phillip Senn
Sent: Thursday, January 26, 2006 3:33 PM
To: [email protected]
Subject: [CFCDev] SQL Scenario

OK, I've been putting off posting this question for some time now because I know that if I were to ask it to anyone on the list individually, the answer would be "Well yeah, if you paid me to come in as a consultant I'd answer your question".  But I woke up this morning realizing that everyone is on the list to learn and teach, so let me share with you what I'm struggling with.

And an answer like "go read Head First Design Patterns" is perfectly acceptable.

 

My company has customers, employees and vendors.  How would you model this in the OO world?

If a customer were to (in essence) SELECT * FROM Orders, it's an implication that what they are really wanting is:

SELECT * FROM Orders WHERE CustomerID = myCustomerID

 

If a vendor were to SELECT * FROM Orders, it's an implication that what they are really wanting is:

SELECT * FROM Orders

INNER JOIN OrderDetail

INNER JOIN Item

WHERE Item.VendorNo = myVendorNo

 

If an employee were to SELECT * FROM Orders, it should SELECT * FROM Orders.

 

Question 2:

It seems to me that the OO design should be very closely aligned to security (or at least filtering) – who can see what.

Example: if an employee goes on vacation, a fellow employee needs to assume the others' responsibilities without logging in as them.  So they need to assume the other persons' rights.

 

Keeping cfcomponent in mind, how would one model this (kind of common) data model in a SQL database?

 

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]

Reply via email to