Going through the BO is easier when you are working within the BO.  The speed will be the same in either case.  The BO calls the code like this:

MicroFour.Data.DataBasics.DataSource(Me.DataSourceKey).ExecuteScalar(PassedCommand)

If they have the same data source key then it makes no difference as they will both execute the command on the same connection...and ExecuteScalar never updates the internal data table.  Obviously, logic generally lends itself to looking at the object that will always be available.

It just occurred to me, is it better to use ExecuteScalar() directly or to use the parent BO and a Get method that uses execute scalar? I.e. which is better



LinkBO - connects to tblWidgetFactoryLink

WidgetFactoryLinkID - pk for tblWidgetFactoryLink

WidgetID - reference to Widget, from tblWidgetFactoryLink

FactoryID - reference to Factory, from tblWidgetFactoryLink

WidgetName - custom property using "Select WidgetName From tblWidget Where WidgetID = @id", @id = currentrow WidgetID, ExecuteScalar(cmd)



OR



LinkBO - connects to tblWidgetFactoryLink

(same fields as above, except...)

WidgetName - custom property using the WidgetBO.GetWidgetNameByID(currentrow WidgetID)



It seems to me that in the first case, you have coupled the LinkBO to the database, while in the second you have coupled it to the WidgetBO. Are there performance issues using the second way? Does the second way improve flexibility, say when moving from a database to a web service?

I will look into the missing help topic.  Thanks.

Ah...light bulb goes on. My brain was refusing to comprehend the curly braces....an array...doh! I'm glad to hear that the approach I'm using is good, cause it makes coding easy and makes the linking BOs very useful, without having to add a bunch of gunk to them.



BTW, in the tutorial help file, it refers to a help topic "Creating Custom Field Properties" is referred to in the "Adding Custom Field Properties" topic (in the tutorial). The "Creating Custom Field Properties" doesn't exit. It says that if the custom property is going to be bound or used a lot, then a custom field descriptor is better. I very likely will need this at some point soon, so I'll be bugging you all for more info (or for the missing help topic)

Create a descriptor for each one.  If you are using the ReflectionPropertyDescriptor, just return an array of the descriptors:

Calling a scalar method is always a good idea when it relates to retrieving a single piece of data...if you put a packate sniffer on your NIC, you will see very little fluff as opposed to a SELECT.  This is why the scalar exists and this is what I would do in this case.

I am attempting to add several custom fields to a BO. Following the instructions in the tutorial, you need to add GetCustomBindablePropertyDescriptors override for the property. What do you do if you have 4 properties (or any number larger than 1?



A second question is related to best practices. I have a linking table, I.e. it links rows from two different tables, say WidgetsID to a FactorID. I want to be able to show the widgets at a factor, and be able to provide some details about the widget. Is it a good idea to use custom properties in the linking BO to do this. I.e. the linking BO will have three fields, the pk field, the WidgetID field and the FactorID field. Is is a good idea to add a WidgetName and WidgetDescription custom field, that use ExecuteScalar() to retreive the name and description using the current row WidgetID? If it isn't a good idea, why? And is the alternative to use a BO to a view?



Thanks!