How to implement a BO that on create has some properties that MIGHT?? already be present

How to implement a BO that on create has some properties that MIGHT?? already be present

Old forum URL: forums.lhotka.net/forums/t/3984.aspx


SethSpearman posted on Tuesday, December 04, 2007

Hello,

I have a business object MEETING with child DOCUMENTS.  These Documents  can be used at more than one meeting  (A policy document being developed and that will be discussed at more than one meeting, for example). 

In the DB I have handled this with 3 tables:  Meetings, Documents, and MeetingDocuments.  Documents is the master list of documents.  MeetingDocuments is the table that stores the assignment of particular Documents to particular meetings.  So it stores the KEY from the documents table.  So MeetingDocuments is a junction table in a many to many relationship.   

I have created an Document BO that is contained in Documents List BO which has meeting as the parent.  So I use syntax like this.  Meeting.Documents.AddNew.

I have been wondering about best practice for setting this up.  When setting up the meeting I want to add a document to a meeting.  The new document may or may not exist in the master Documents table.  So I create a new document object like this. 

doc=Meeting.Documents.AddNew

Then I link the document to the key of the master documents table like this:
doc.DocumentID=myGuidKey  'where my guid key was EITHER a new(dummy) key for a new document that I want to add to the master table.  OR the key was looked up in  the master table from a list in the UI. 

One sticking point is that my Document BO will need to fetch a couple of fields from the master table OR supply new values.  The properties are Name and Description.  So the situation is that for existing documents in the master table, I want to supply a document ID and FETCH the corresponding Name and Description.  In this case the Meeting.Document would be READONLY on these properties. 

For NEW documents the properties will be settable UNTIL the first save.  After that you would have to open the standalone Documents root list to edit the Name and Description or other values. 

I am not really asking a CODING question with one exception I will get to below.  I mostly want to know if this approach is correct.  This is a best practices (what did you do in a similar situation) question.  Is this approach correct or should I keep those properties in another BO that would be a one-to-one child of Meeting.Documents(x) or some other approach. 

About the coding question...I think that I need to disable the AddNewCore that I have implemented in the DocumentList object.  Because I suppose I should REQUIRE that the DocumentID (be supplied when the  Meeting.Document is created.  All of my list object have implemented AddNewCore and I am not sure how to create the object and all the while REQUIRE that a documentID be supplied.

Sorry for the long question.  In summary I am only asking two questions:

Is this approach the best?
How do I supply a docID at create time for Meeting.Document?

Thanks for all you guys do to help us newbies.

Seth B Spearman

Copyright (c) Marimer LLC