Binding Business Object Properties to RDBMS Tables

Binding Business Object Properties to RDBMS Tables

• HypeH

  I guess this was just a really hard question, hunh
  
  Since I've never found a substantive response on three forums.
  
  Hmmm....
  

• Petya

  Thanks for the input.

  I don't know what this means:

  "dynamically bind the table to the object using reflection"
  
  I think that for me, it gets down to a preference for ".property" syntax versus DataRow("ColumnName") syntax. (I like the way the available fields pop up for selection when coding...)
  
  I'm using DataTable 1) to have access to the dataadatper and avoid writing a lot of SQL, and 2) to avoid disk write latency.
  
  QUESTION >>> In this scenario, I'm wondering how much performance penalty there would be to add the object layer "get" and "set" properties on top of the DataTable.

  From a practical standpoint, I've just stuck the DataTable in the object so I can drag it around, take it out and update it when I need to, but I haven't exposed the table elements in any external functions. That's an interesting thought...like...

  BizObj.GetRowFieldValue(wrkPrimaryKeyValue, "ColumnName")

  BizObj.SetRowFieldValue(wrkPrimaryKeyValue, "ColumnName", wrkValue)

  BizObj.RowAdd(wrkRow)

  BizObj.RowDelete(wrkPrimaryKeyValue)

  Hmmmm.....

  
  

• AceHack

  there is plenty of documentation on MSDN regarding the GetType, GetProperty and SetValue method.

  All objects in .net derive from object and have the GetType method, which is used extensively when you need to hold a reference to a type (the other ways are to use typeof(myobject) or instantiate a type using the Reflection namespace).

  GetProperty is basically used when you don't know at compile time the name of the property, or can be used to reduce the amount of code when you need to set several property values (you could use GetProperties to get all the properties or an object or class and certain parameters allow you to filter the result, such as only public properties for example), it also allows you to modify private properties that otherwise wouldn't be available.

  If simplicity and not performance is the goal, then the DataAdapter is the way to go, it will considerably reduce the amount of code you need to write to achieve the same, but of course, it has a cost.

  Using the datadapter won't get you tied to a particular database if that's what you mean, yes, for Oracle or SQL Server there are specifics DataAdapter (and specific connections, commands, parameters, datareaders, etc.) but they all basically have the same methods, so it wouldn't be too difficult to adapt to a different database.

  Of course, if you are using .net you are tied to MS, since .net only runs on Windows (there is a project to port .net to Linux but as far as I know it's still beta and limited in functionality).

  
  

• Kees_de_Waard

  Hi,

  I think I don't fully understand your question but I can guess what you want. Do you mean that you want your object persistable to the RDBMS If true, I think your solution maybe able to find at NHibernate.

  From my reading, I think MS is expecting people to treat database table row as an object. So that you can use a dataset to represent a collection of that object. Afterward, you can bind to many kind of controls with the dataset. However, I believe this approach limit the flexibility of an object (treated as a table row only).

  Hope this help.

  
  
  

• J.13.Leach

  RicardoJB:  Thanks for the input.  I'll do the research on GetType etc.
  
  Re:  independence:  I'm using ASP.NET because I need to offer "no prior notice, no download restrictions" user access, and MS had the easiest on-ramp appropriate to my skill set.  So independence is relative....really a matter of writing the custom business objects so that the webform handling and data access handling routines are relatively segregated from the busines logic, in case there's a value to implementing somewhere else later.

  A background context for much of this is resource consumption, that is (I'm reaching here...) how much of a server is the app burning up, in terms of disk hits, memory hits and memory usage.   And the in-memory persistent datasets, and the cha-chunk instantiation of dataadapters has got to have some impact.

  I started some research a while back on how ASP.NET apps behave in the real world of service bureau (or in-house) server consumption and what the constraints are, but the material didn't jump out at me from Google, in terms of how to understand what the actual tradeoffs are among of "ease of development", "profligate use of memory and CPU cycles", and rent-a-server costs.   Probably should talk to the service people directly...

  Any ideas on approaching that subject

    

  
  

• J. D. Laflen

  There isn't any specific class to do that.

  You have a few options.

  One would be to dynamically bind the table to the object using reflection, you could use the same name for your properties and table fields, this of course has a performance penalty.

  Another option is to make the object serializable and then save it as an xml data type on the database, again, performance.

  A third options would be the have a DataRow as a private field in your class, and then have each property accessing fields of the datarow with their get and set accessors.

  You could have a property DataRow used to assign a particular row to a particular object. Because the datarow is an object itself, if it gets modified anywhere it would automatically reflect in your object.

  Be careful though with additions and deletions, you have to make sure you keep them in synch, you don't want an object holding a reference to a null row.

  Depending on what you want to do you can pick an approach, often is easier and faster to just have a method that updates the properties to and from the datarow, of course, not practical if you have many properties.

  
  

• tgbk

  Thanks for that input. I'll take a closer look at Typed DataSets.

  
  

• nunhuck

  Have you considered Typed Datasets Which will give you the same ease of loading and saving data as a usual dataset but the benefits of business objects in the UI such as Customer.FirstName
  

• Adagio59675

  You can dynamically assign values to properties using reflection, if you for example name your database fields with the same name as the properties, you could use that name to update the corresponding property.

  something like this:

  MyObject.GetType().GetProperty("PropertyName").SetValue(MyObject, "something");

  of course this should always be in a try catch block and it might be more complicated than that depending on your class.

  The get and set accessors don't add much overhead if the property just gets or sets the value of a field, if you are doing some processing inside them then there might be a performance penalty, depending on what you are doing.

  If you are concerned about performance, you should really not use a dataset, dataadapter or tableadapter, these are heavy objects that take a lot of resource, they are easy to use but you pay a price for that.

  it's better to use a DataReader and populate business object IMO, that will also give you a lot more flexibility down the road.

  You will have to make a decision to whether you want performance or easy coding, I personally avoid the datasets whenever I can because they are heavy, they are more intended to fast development, but even though they are objects and you can somehow choose its "properties", they don't offer the flexibility I need most of the times.

  I can't tell for sure, but it seems to me that MS is trying to quietly walk away from the dataset/dataadapter model they promoted so much on 1.1 and 1.0.

  
  

• eng2chi

  Thanks for the message.

  I'm still not grasping the usage:

  MyObject.GetType().GetProperty("PropertyName").SetValue(MyObject, "something");

  Could you suggest some references on this
  

  The priority in my project right now is ease of coding, though independence of technology is key, too, and the dataadapter model definitely causes some "buy-in" there.

  I'll take a look at DataReader; though I sure like the way the DataAdapter generates all the writes and updates.

  Also, I've decided it's easy enough to pick fields from rows using the myRow("myColumn") notation. I suspect for other environments it would be helpful to have a class with properties so that coding mistakes would be avoided.

  Maybe an special class that gets and sets the datarow field values without storing them anywhere except the datatable

  
  

• Nick65465464

  I converted to a tableadapter and typed datasets, and it made a huge difference in terms of my sense of confidence in the code. Having the intellisense confirm that the fields are being accessed properly, and the built-in "findbyprimarykey" function are a big help. The tableadapter code is very compact also, and the general compactness of the typed code make it a lot easier to follow the busines logic. Of course....

  "First one's free...."

  (I don't think I'll be converting to JSEE anytime soon...)

  That aside, this is mostly what I was looking for in terms of the original impetus for the thread. Wrapping a business object around the typed data table produces pretty much the whole effect. Mapping directly from the DB to a custom object without the typed table in-between is would seem to be a fairly exotic ORM type exercise and is clearly way past my needs.

  So far, so good!

  
  

• Chandra_SQL

  Thanks for your message. Since writing that post, and thanks to your prompt, I put it together to see that objectdatasource "get method" results can only be a dataset, datatable or dataview...which means that this isn't really about "custom" business objects at all....and so that's not a good take-off point for asking about binding custom business objects to database elements.

  In other words, the question was based on flawed assumptions, erroneous logic, and newbit naivity. Oh, well!

  So, in that perspective, I'm pretty sure that the idea of binding custom business objects to database entities DOES fall into the category of "ORM", which, based on a quick review from the web, is interesting (and worth it) only if you're very deep into OO.

  Not this week.

  Merci!

  
  
• Binding Business Object Properties to RDBMS Tables