locked
Data Tables vs Business Objects ? RRS feed

  • Question

  • User852864959 posted

    Hello,

    Your kind attention and expert advice is required please, here I want to disucss using Data Tables instead of Business objects for passing data between layers and to bind controls (I am not saying DataSet vs BusinessObjects rather DataTables vs BusinessObjets)

    In my architechture I have (1) User Interface, (2) a project containing Custom Types or business objects, (3) a business logic layer and (4) data access layer. Further more I use stored procedure in database.

    As a developer of course my privorities are code reuseability, fast development and quality of work. I have felt that using business object saves development time in the following ways.

    1. It allows immplementing business logic through properties

    2. They are easy to create in VS 2008

    3. They save time of passing seprate parameters to functions and reduce errors that can raised by passing a lot of  parameters individually.

    But antoher fact I observed is that using Business Objects for filling data from DataReader waste some time as well. Suppose my stored procedure is returing 20 columns. I will have to catch and fill every column individually but if I just start using DataTable just writing one line of code will save me from writing 20 lines of code. I am in team as senior and I felt every one waste some time doing this.

     

    If as a developer we value code reuseability, fast development and quality of work what you say about using DataTable instead of using Business Objects. Another tpositive thing is that in DataTable there are some built in featurs that we may have to do by overself if we go for buliness objects. Using DataTable is also less bulky than Data Set and  speedy than Data Adapter.

    Please advice me how you see using business object for implemnting logic, busines rules and passing arguments and use data table (typed or may be untyped) to pass data taken from db to different layers and to bind controls. I am using Enter Prize Library DAAB for database communication.

    Thanks in anticipation for your attention, advice and precious time.

    Haansi

     

     

    Monday, February 22, 2010 2:05 AM

Answers

  • User-821857111 posted

    My preference is for Business Objects. You can develop a tool to populate their properties from the database if you like. That's the basis of most ORMs like Linq to Sql, EF, nHibernate etc. That will save your team some time in the long run.


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, February 22, 2010 2:47 AM
  • User-952121411 posted

    Typically the preferred method is to use custom business objects over any type of ADO.NET object.  There are several advantages of business objects and I can list a few of them out here for you:

    • Objects have behavior and encapsulate functionality to a specific business purpose.  Using basic OOP principals, the importance of separation of concerns and encapsulation are something you can not achieve with a DataTable that just has been populated from a Database.  The DataTable has no behavior or meaning, but is just a type to store data.
    • Unless you are using something that is strongly typed in ADO.NET, referencing values within a DataTable will cause you to scatter hardcoded fieldname references throughout the application including the UI.  Basic tools like Intellisense in VS.NET make developing much easier and less error proned, and will be more difficult to achieve with a DataTable.  If the field name ever changes, the hardcoded references are scattered all throughout the application, where with an object, the reference is probably only made in 1 place, and will probably only require changes in a single layer. Look at the code example below:
    'Referencing a field in a DataTable
    Dim LastName As String = dt.rows(0).Items("LastName").ToString()
    'Referncing a field in a custom object
    Dim LastName As String = MyBusniessObject.LastName
    
    
    • Since the .NET Framework 2.0 we have had the power of Generics and using List(of MyClass) to create powerful lists of objects, which essentially creates a strongly typed list of objects.  These by nature implement the interfaces needed for binding most controls, and become quite powerful at all layers of the application.  Passing a List(of MyClass) is preferred IMO to passing around a DataTable with raw data.  If you have not looked into this before take a look at the following link:

              .NET Object Collections Using Generics 101:

              http://allen-conway-dotnet.blogspot.com/2009/11/net-object-collections-using-generics.html

     

    • ADO.NET types like DataTables and DataSets can not house business rules nor expose methods of any type like objects do, and therefore the rules end up getting scattered throughout including the UI.  This can increase maintenance time and reduce scalability.

     

    Lastly, I think you should look into using Business Objects and object collections like described in the link above as a better architecture.  If you want to read some more discussions on this topic check out the following links:

    Why should you use business objects in .NET and not DataSets?

    http://www.kellermansoftware.com/t-articlebusinessobjects.aspx

    Objects vs. DataSets - Is it Really About the Technical Aspects?

    http://davidhayden.com/blog/dave/archive/2005/07/27/2406.aspx

    DataSets vs. Collections:

    http://blogs.msdn.com/reinouth/archive/2006/03/08/546510.aspx

    Also, for all of these points, realize a DataTable which you use is just a single object which could make up a DataSet (1..n Tables in a DataSet) so the conversations about DataSets vs Objects are applicable as well.

    Hope this helps! Smile


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, February 22, 2010 1:56 PM

All replies

  • User-821857111 posted

    My preference is for Business Objects. You can develop a tool to populate their properties from the database if you like. That's the basis of most ORMs like Linq to Sql, EF, nHibernate etc. That will save your team some time in the long run.


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, February 22, 2010 2:47 AM
  • User-1636183269 posted

    I will prefer Bussiness objects, if you will create your application in CSLA- Business object then you can create your application not only performance also scalable.

    <input id="gwProxy" type="hidden"><!--Session data--><input onclick="jsCall();" id="jsProxy" type="hidden">

    Monday, February 22, 2010 2:54 AM
  • User852864959 posted

    Thanks Mikesdotnetting for taking care and guiding.

    I will thakful if you guide me some more. From your reply I have further questions to ask please.

    1. You wrote you will prefer objects, but why ? Like I mentioned what problems I am facing. Can you please guide me what is reason for this please like is there some benefit in them (I am comparing objects with data tables and not with data sets).

    2. Regarding tool can you please explain it a little more ? Is there one already available for free ? Or any help on developing one.

    thanks once again.

    <input id="gwProxy" type="hidden"><!--Session data--><input onclick="jsCall();" id="jsProxy" type="hidden">

    Monday, February 22, 2010 4:02 AM
  • User852864959 posted

    Thanks Das.Sandeep,

    Can you please guide why you will prefer. Like What I described is not a flexible way.

    I was not aware of CSLA thanks for it, I am searching on it. If possible please can you mention more about this.

    thanks


    <input id="gwProxy" type="hidden"><!--Session data--><input onclick="jsCall();" id="jsProxy" type="hidden">

    Monday, February 22, 2010 4:49 AM
  • User-1199946673 posted

    I was not aware of CSLA thanks for it, I am searching on it. If possible please can you mention more about this
     

    http://www.lhotka.net/

    Monday, February 22, 2010 5:10 AM
  • User-952121411 posted

    Typically the preferred method is to use custom business objects over any type of ADO.NET object.  There are several advantages of business objects and I can list a few of them out here for you:

    • Objects have behavior and encapsulate functionality to a specific business purpose.  Using basic OOP principals, the importance of separation of concerns and encapsulation are something you can not achieve with a DataTable that just has been populated from a Database.  The DataTable has no behavior or meaning, but is just a type to store data.
    • Unless you are using something that is strongly typed in ADO.NET, referencing values within a DataTable will cause you to scatter hardcoded fieldname references throughout the application including the UI.  Basic tools like Intellisense in VS.NET make developing much easier and less error proned, and will be more difficult to achieve with a DataTable.  If the field name ever changes, the hardcoded references are scattered all throughout the application, where with an object, the reference is probably only made in 1 place, and will probably only require changes in a single layer. Look at the code example below:
    'Referencing a field in a DataTable
    Dim LastName As String = dt.rows(0).Items("LastName").ToString()
    'Referncing a field in a custom object
    Dim LastName As String = MyBusniessObject.LastName
    
    
    • Since the .NET Framework 2.0 we have had the power of Generics and using List(of MyClass) to create powerful lists of objects, which essentially creates a strongly typed list of objects.  These by nature implement the interfaces needed for binding most controls, and become quite powerful at all layers of the application.  Passing a List(of MyClass) is preferred IMO to passing around a DataTable with raw data.  If you have not looked into this before take a look at the following link:

              .NET Object Collections Using Generics 101:

              http://allen-conway-dotnet.blogspot.com/2009/11/net-object-collections-using-generics.html

     

    • ADO.NET types like DataTables and DataSets can not house business rules nor expose methods of any type like objects do, and therefore the rules end up getting scattered throughout including the UI.  This can increase maintenance time and reduce scalability.

     

    Lastly, I think you should look into using Business Objects and object collections like described in the link above as a better architecture.  If you want to read some more discussions on this topic check out the following links:

    Why should you use business objects in .NET and not DataSets?

    http://www.kellermansoftware.com/t-articlebusinessobjects.aspx

    Objects vs. DataSets - Is it Really About the Technical Aspects?

    http://davidhayden.com/blog/dave/archive/2005/07/27/2406.aspx

    DataSets vs. Collections:

    http://blogs.msdn.com/reinouth/archive/2006/03/08/546510.aspx

    Also, for all of these points, realize a DataTable which you use is just a single object which could make up a DataSet (1..n Tables in a DataSet) so the conversations about DataSets vs Objects are applicable as well.

    Hope this helps! Smile


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, February 22, 2010 1:56 PM