Data Store information in Business Object

strick9 posted on Thursday, July 19, 2007

Hello, and welcome to my first post. I have been looking at and experimenting with CSLA for a couple of days now, so please forgive if I have overlooked an obvious answer or I am using incorrect analysis here. If I have overlooked something, feel free to just send page numbers for the VB Book and some deserving noob comments.

We are working through proof-of-concepts before beginning a massive project. One item that we want to provide in the PL is the table and name (later formula or notes) that describe where the data came from. I could simply store this info in properties of each item as it returns to the PL, however, that seems like it would bloat the data. So my question is this…

Is the best place to put this information as properties or a dictionary in the business object?

strick9 replied on Thursday, July 19, 2007

Sorry, it's probably just that I'm new here. PL-Presentation Layer. We plan on showing the data store tablename and field name in the control tooltiptext for the user to understand where the data came from.

triplea replied on Thursday, July 19, 2007

That would go a bit against what Rocky and others have mentioned before - 1 table is not (or should not be) 1 object. Objects are based on behaviour and not on the data structure of the data source. In any case I guess if you have multiple tables (e.g. Customer, Client etc...) and they all have the same behaviour, you could populate the Person.SourceTableName property based on the passed criteria to fetch the data. But not sure this is ideal...
Regarding the properties, there could be a numbe of ways of dealing with the problem but you might want to reconsider your approach...

strick9 replied on Thursday, July 19, 2007

triplea, it sound like you are mentioning one of the posibilities that I was considering. "you could populate the Person.SourceTableName property". Would this property then be stored for every item in a SortedBindingList (for example)?

triplea replied on Thursday, July 19, 2007

Well if you had a list then I guess yes you could do that. E.g. if you pass on a criteria such as criteria.IsConsumer = true and then you do something like a UNION in your select (e.g. select 'Customer' as tablename,* from Customer where... UNION ALL select 'moneyspender' as tablename,* from moneyspender where ...) that would sort it out.
In any case check what Rocky posted because it seems you might be moving away of the concept of CSLA (and object modelling alltogether) which really requires you to think of your objects as completly different entities from your database structure.
Instead of the above simplified approach why don't you create a base abstract class Consumer with properties and methods common to both Customer and MoneySpender? Then you can override the appropriate methods in the implementation of these classes (e.g. the dataportal methods).
Then you could have a list as the datasource of your SortedBindingList that contains objects of type Customer and then you don't need to worry about the tablename being a property of you object...

RockfordLhotka replied on Thursday, July 19, 2007

So when you say "table and name" you aren't talking about database table - you are talking about some business domain concept of a table. Like one with four legs?

If that's the case, then it sounds like your table, name, formula and notes are all part of your data - or at least are meta-data about your data.

What you need to do is examine your application from the perspective of user scenarios, or use cases. If a use case requires this data, then the objects implementing that use case should, by definition, include that information.

The UI should never get data or business behaviors from anywhere except the business object layer. Properly designed business objects will fulfill the needs of the use case, and thus the needs of the UI within the context of that use case.

strick9 replied on Thursday, July 19, 2007

Rocky,
I should have been more specific to begin with.
Let's say that I am fetching for a SortedBindingList the following... "SELECT InvoiceNo FROM APInvoices Where CompanyNo = 1 ORDER BY InvDate"
What I would like my users to see when they hover over a column of data in a grid control is "Invoice Number AS InvoiceNo IN APInvoices". That way they can know where it all began.
Sorry for my vaugeness earlier. I wasn't sure what to ask at first. What I don't want to do is have this data as a property in the InvoicesList class as part of the data in my business object. I thought there may be a place that I can make this a property for all my business objects so that lists and others would only hold the database field and table names once.
Is that more understandable?
(BTW-Thanks to all for the active responses)

triplea replied on Thursday, July 19, 2007

Sorry I got a bit carried away in the previous post... I can't think of a clearer way to display the tablename. I have seen something similar and the way it was tackled was the following (awful) way. SourceTableName was a property (hardcoded as a constant in your class). In order to keep it consistent with your datasource, you could use it to construct a string which would be your SQL string. So in your Fetch method do something like:
string sql = string.Format("select * from {0} where...", _tableName)
Now that's no good (even though it would give you some kind of reassurance that the data displayed is actually where you are fetching your data from)...
Alternatively, you could have a Fetch stored procedure which after the SELECT * FROM Customer has a statement like: SELECT 'Customer' AS SourceTableName. This way you keep both together and can somehow manage changes.
Column names that your proerties correspond to I can only think something along the lines of using attributes to decorate your properties (e.g. [ColumnType("CustomerName")]) and have a seperate class map that attribute with a list of columns from your source table.

strick9 replied on Thursday, July 19, 2007

" Sorry I got a bit carried away..."
That's ok, any discussion is good for my though process. I'll approach the stored procedure idea, but I'm not sure what that will take (not a SQLServer backend, DB2 on iSeries). Some kind of mapping of the names may be the way I go.
In any case, thanks for your time and ideas (you too Rocky). And thanks to everyone for demonstrating an active project/community. I'll be back.