Just curious to see how everyone else is handling this. We have a Project and it is associated to a Customer. The Project BO has a read/write property called CustomerID and a read property called CustomerName. We need to display the friendly name of the Customer, but not allow the user to modify it. Now when the user changes the Customer for the Project, we respond to the PropertyChanged event for CustomerID and update the value of CustomerName from the DB.
While this is nice in a small class, we have some classes that have multiple foreign key references and I'm just concerned this may get a bit database intensive.
Any other thoughts or is this how everyone else is handling it?
Thanks! Matt
d0tnetdude:
Just curious to see how everyone else is handling this. We have a Project and it is associated to a Customer. The Project BO has a read/write property called CustomerID and a read property called CustomerName. We need to display the friendly name of the Customer, but not allow the user to modify it. Now when the user changes the Customer for the Project, we respond to the PropertyChanged event for CustomerID and update the value of CustomerName from the DB.
While this is nice in a small class, we have some classes that have multiple foreign key references and I'm just concerned this may get a bit database intensive.
I often create a set of GetPublicId functions for all my database tables. Each function is responsible for returning a user-understandable text value that uniquely identifies the record to the user.
So, on a Person table, I would have a "PersonGetPublicId( PersonId int)" database function. It returns a string value like "Lhotka, Rockford P (Emp# 12345)".
That makes it easy for a programmer to get a useful, standardized string to pass back for error messages, brief descriptive labels, etc. They are particularly useful for feeding NVList classes, particularly if your BO programmers don't understand the database as well as you would like.
The same concept could be used on the BO side of the code, except you would add a static function to the various business objects (and a property as well.)
That's kind of what I am doing now ... I have a helper class I call DBValue, that takes a Table Name, ValueColumnName, and DisplayColumnName (what is returned). I have a Friend Shared Function on my Customer class called GetCustomerName(customerID). This returns the String representation of the Customer Name and sets in the Project object. I also need to start checking to make sure the CustomerID even exists, for now, I assume it does, but could I somehow roll that into this as well or would this be another database hit? Or am I over reacting to the interaction with the database?
Thanks! Matt
d0tnetdude:
That's kind of what I am doing now ... I have a helper class I call DBValue, that takes a Table Name, ValueColumnName, and DisplayColumnName (what is returned). I have a Friend Shared Function on my Customer class called GetCustomerName(customerID).
This returns the String representation of the Customer Name and sets in the Project object. I also need to start checking to make sure the CustomerID even exists, for now, I assume it does, but could I somehow roll that into this as well or would this be another database hit? Or am I over reacting to the interaction with the database?
Nope ... it's not in the UI, it's in a Friend helper class in the Business Layer! ![Smile [:)]](/emoticons/emotion-1.gif)
My thinking is that I don't want to assume the UI is passing me a valid CustomerID, and I want the business objects to handle the validation, as opposed to a SqlException when the foreign key relationship is not valid. The old way we did it was to let the UI set the CustomerID and set the CustomerName, the latter was meaningless as the next time the Project object was loaded it would retrieve the CustomerName.
I am just trying to make the Business Objects do more of the validating and helping with the assignment of foreign key related variables, like the Name of the Project or the Name of the resources assigned to the Project. My thinking is that I can make the UI even easier to code, by having more of the funtionality at the Business Object Layer. My Business Objects will get "fat", but I'm not sure if that is really a problem. Just interested to see how everyone else is doing this.
This is prevelant in my applications. The way I have implemented this is to use a similar type of lazy-load approach as Rocky did in ProjectTracker. Here's an example:
public System.Guid Customer
{
This accomplishes the same thing by retrieving the customer record from the db and setting the internal variable to the name, but the overhead is not incurred unless the value is actually needed.
Note that I invalidate the _customerName variable in the Customer property setter. This ensures that the correct value is returned should the id property be changed. No need to handle any events this way.
HTH
P.S. I should add that for my read-only classes that are used strictly to display the object in lists, I create a View in the db and return either both in the result set or just the name. What is shown above would only be used in an editable (child) object.
Copyright (c) Marimer LLC