Business Object Stereotypes

DougZ posted on Tuesday, November 21, 2006

Hi.  I am new to the CSLA framework, and I am trying to design classes for a new system using CSLA.  So, get ready because this probably will not be my only post.  The system will be for managing the process of recruiting firefighters from gathering job interest, accepting applications, testing applicants, and reviewing those eligible for hire.  Right now, I am working through the concept of the business object stereotypes (and their code templates provided by Rocky).  I am reading the book, and I have downloaded the code.  Is there a resource that provides a clear and concise explanation of each stereotype (Editable Root, Read-Only Child, etc.) and what criteria you should use when deciding which one fits your business object?  So far, I have been using Chapter 7 in the book and supplementing that with these forums, but I still have questions.

Thanks,
Doug

Bayu replied on Tuesday, November 21, 2006

www.onelittlevictory.com

Excellent resource that will answer some of your questions.


Bayu

DougZ replied on Tuesday, November 21, 2006

Bayu,

Thanks.  I did read through that page already, but I'll revisit it.  I wish it had more info than just a one-sentence explanation of each stereotype.

Thanks,
Doug

Bayu replied on Wednesday, November 22, 2006

DougZ:

Bayu,

Thanks.  I did read through that page already, but I'll revisit it.  I wish it had more info than just a one-sentence explanation of each stereotype.

Thanks,
Doug

In that case, perhaps pose your specific questions here .... ?

Bayu

DougZ replied on Wednesday, November 22, 2006

Bayu,

Sure, let's start with the one I posted a few messages up regarding Editable Child objects.  Could you take a look at that and tell me what you think?

Thanks,
Doug

Bayu replied on Wednesday, November 22, 2006

Ah,

Sorry, I missed that one. ;-)

The difference that is hinted at here is the following I believe:
- you can have a list of editable children (1-to-many)
- or you can have a single editable child (1-to-1)

In both scenario's there is a compelling reason why the child object(s) cannot 'live' without the parent (like you said, invoice items require an invoice to make sense). An example of the single parent-single child (i.e. 1-to-1 relation) would be a PC that has a single Keyboard (sorry, I was looking around me for inspiration, this is just the first thing that come to mind ;-D ). This is of course assuming that your particular application has a use case where a keyboard can not go without its corresponding PC (I know, it's not a compelling example, but it gives you the idea).

Bayu

DougZ replied on Wednesday, November 22, 2006

Bayu,

OK, I think I've got it.  An Editable Child object can be used in a collection of Editable Child objects (i.e. an Editable Child List) owned by its parent object (e.g. a PC has a USBPortList consisting of USBPort objects), or an Editable Child object can be used for a single object whose existence depends on its parent object (e.g. a PC has a Keyboard).  The difference seems to just be in the multiplicity of the relationship.  Right?

Thanks,
Doug

Bayu replied on Wednesday, November 22, 2006

DougZ:

Bayu,

OK, I think I've got it.  An Editable Child object can be used in a collection of Editable Child objects (i.e. an Editable Child List) owned by its parent object (e.g. a PC has a USBPortList consisting of USBPort objects), or an Editable Child object can be used for a single object whose existence depends on its parent object (e.g. a PC has a Keyboard).  The difference seems to just be in the multiplicity of the relationship.  Right?

Thanks,
Doug

Correct.





Bayu

DougZ replied on Tuesday, November 21, 2006

Here's an example.  This comes from onelittlevictory describing Editable Child objects:

"An Editable Child Object is used to populate an editable collection of objects contained in a parent object OR when a fully functional editable object needs to be contained within a parent root object."

So, the first situation would be like an Invoice with an InvoiceItemList populated with InvoiceItem objects ... the InvoiceItem objects are Editable Child objects, right?  Can someone give me an example of "a fully functional editable object (that) needs to be contained within a parent root object"?  Also, shouldn't it just say, "within a parent object," since an object can be a child of a child? 

Thanks,
Doug

guyroch replied on Tuesday, November 21, 2006

Doug, take a look at this link as well

http://www.primos.com.au/primos/Articles/CSLAversion2whatsinitforme/tabid/67/Default.aspx