none
should I use DataSet as my domain object directly, or use DataSet to load/save my domain objects at beginning and end??? RRS feed

  • Question

  • Hi,

    For a simple app I have with only a few tables, I'm getting the hang of Datasets, however now I am procrastinating over whether I should:
    1. Let my business logic work directly with the DataSet itself - so that my domain model is the DataSet itself in a way, OR
    2. Just use the DataSet to load/save/update my domain objects I create - in my case my domain objects are just a list of a specific class (so nothing too complicated) - this would seem a good decoupled way to go, but I start to see that I'll end up duplicating some code (i.e. plumbing type code).   Also what happens if I want to do piecemeal updates with this option (as opposed to a load of config at beginning of app, and then a SAVE at end).  This means I would have to keep my business objects in sync with a DataSet anyway no...
    Any advice on a nice simple way to use a database with just a few tables?  (i.e. drop domain layer & just go with using the Dataset)

    thanks
    Sunday, October 18, 2009 11:28 AM

Answers

  • I don't know if there's a "best practices" out there for using DataSets in this manner. But, here are a few options:

    1) Make some DataSet extension methods for some things. All my DataSets have a method I call FillWithXml(string xml). It's a three line method (basically to call the DataSet's native ReadXml() method using a StringReader) because I fill my DataSets with an XML string passed thru Web Services. Anyway, it's these are the types of methods that would make good extension methods.

    2) Partial classes: Additional functionality for specific DataSets could be added via partial classes. This has pros and cons ... depending on how you conceptualize your DataSet. If you see it simply as a data transport mechanism, then perhaps it's best not to put this kind of functionality as part of the DataSet and do it instead via option #3 below.

    3) Business classes: You can have some other classes that you use to manipulate your DataSets (call them business  or domain objects, I don't suppose it matters what terminology you use). Any work you need to do to your DataSet would be done in these classes, rather than in a partial class of the DataSet itself.

    You can also mix-and-match the above 3 options ... I have. There are no hard-and-fast rules. Whatever "feels right" to you. ;0)
    ~~Bonnie Berent [C# MVP]

    geek-goddess-bonnie.blogspot.com
    Monday, October 19, 2009 4:33 PM
  • 1) >>do you mean that you would actually use inheritance to extend the DataSet<< No, .NET 3.5 now has something called extension methods. You can read about it here (C# http://msdn.microsoft.com/en-us/library/bb383977.aspx and VB http://msdn.microsoft.com/en-us/library/bb384936.aspx

    Option 3 does not involve anything static ... it involves an instance of your "biz object", passing the DataSet to it, calling methods on it, etc. When you're done with your biz object, you're done with it. You'd most likely keep it alive the entire time while you're working in a Form.  But, if you need it again, you create another instance of the biz object. Having you DataSet be static there is not a good idea I don't think.

    Something along these lines:

    public class MyBiz
    {
        private MyDataSet oData;

        public MyBiz(MyDataSet ds)
        {
            this.oData = ds;
        }
        public void WhateverMethod()
        {
            // do stuff here
        }
    }
    ~~Bonnie Berent [C# MVP]

    geek-goddess-bonnie.blogspot.com
    Tuesday, October 20, 2009 12:12 AM

All replies

  • If you want to go the domain object route, then you'll probably want/need some kind of mapping helper to keep the database/DataSet tables in sync with your domain classes.

    If you want to keep it simple, stay with using the DataSet itself as your domain model ... pass the DataSet around between your layers.  I've been using DataSets in this manner for more than 7 years and it works great. Of course, I started out doing this back in the 1.1 days and things have changed dramatically since then ... is one way better than the other? Not having played much with any domain model other than a DataSet, I can't give an objective opinion about that.
    ~~Bonnie Berent [C# MVP]

    geek-goddess-bonnie.blogspot.com
    Sunday, October 18, 2009 4:29 PM
  • that sounds logical Bonnie - I had started by creating an interface to isolate the data layer from my domain layer, but then when it came to passing the objects backwards & forwards it does seem apparent that passing the dataset would be easier.   I guess this implies there's no reason for me to have the abstraction layer then.

    If I wanted to add some higher level helper methods (for things I'll do multiple times) associated with the dataset, I'm wondering what a good way to go would be.   To extend the dataset and add my own help methods in here perhaps?  I don't suppose there are any sample code/patterns on how best to do this?  (i.e. take the "pass around the dataset" through the domain layer, but with a way to add common methods you'll be using that align directly with the structure of the dataset)

    thanks
    Monday, October 19, 2009 1:37 AM
  • Hi callagga,

     

    I also prefer to make it simple by passing the DataSet among the multiple layers.  If some additional helper methods are needed, I think you can extend the current DataSet class if it is a strongly typed DataSet.  Strongly typed DataSet are actually partial class, so we can define our own methods, fields or properties to extend it.   

     

    If it is a normal DataSet object and you are using Visual Studio 2008, Extension Methods (C#, VB.NET) which are newly introduced into C# 3.0 and VB.NET 9.0 could be another option to create some helper method. 

     

     

    Hope you have a nice day!

     

     

    Best Regards,
    Lingzhi Sun


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, October 19, 2009 8:05 AM
    Moderator
  • I don't know if there's a "best practices" out there for using DataSets in this manner. But, here are a few options:

    1) Make some DataSet extension methods for some things. All my DataSets have a method I call FillWithXml(string xml). It's a three line method (basically to call the DataSet's native ReadXml() method using a StringReader) because I fill my DataSets with an XML string passed thru Web Services. Anyway, it's these are the types of methods that would make good extension methods.

    2) Partial classes: Additional functionality for specific DataSets could be added via partial classes. This has pros and cons ... depending on how you conceptualize your DataSet. If you see it simply as a data transport mechanism, then perhaps it's best not to put this kind of functionality as part of the DataSet and do it instead via option #3 below.

    3) Business classes: You can have some other classes that you use to manipulate your DataSets (call them business  or domain objects, I don't suppose it matters what terminology you use). Any work you need to do to your DataSet would be done in these classes, rather than in a partial class of the DataSet itself.

    You can also mix-and-match the above 3 options ... I have. There are no hard-and-fast rules. Whatever "feels right" to you. ;0)
    ~~Bonnie Berent [C# MVP]

    geek-goddess-bonnie.blogspot.com
    Monday, October 19, 2009 4:33 PM
  • thanks Bonnie - that's exactly the type of thing I was curious about

    Re (1) do you mean that you would actually use inheritance to extend the DataSet?  For example to "SpecificDataSet", so that the instance of a "SpecificDataSet" has the normal DataSet operations at hand as well as the added methods?  If you didn't do this and just created a separate class you'd have to hold a static instance to your dataset within the class and then have to always go CustomInstance.dataset.xxx all the time I guess, which then would be your option (3).  Did I understand you correct?

    Re Partial classes - I'll have to read up as I'm crossing over to C# here  :)


    Monday, October 19, 2009 11:01 PM
  • 1) >>do you mean that you would actually use inheritance to extend the DataSet<< No, .NET 3.5 now has something called extension methods. You can read about it here (C# http://msdn.microsoft.com/en-us/library/bb383977.aspx and VB http://msdn.microsoft.com/en-us/library/bb384936.aspx

    Option 3 does not involve anything static ... it involves an instance of your "biz object", passing the DataSet to it, calling methods on it, etc. When you're done with your biz object, you're done with it. You'd most likely keep it alive the entire time while you're working in a Form.  But, if you need it again, you create another instance of the biz object. Having you DataSet be static there is not a good idea I don't think.

    Something along these lines:

    public class MyBiz
    {
        private MyDataSet oData;

        public MyBiz(MyDataSet ds)
        {
            this.oData = ds;
        }
        public void WhateverMethod()
        {
            // do stuff here
        }
    }
    ~~Bonnie Berent [C# MVP]

    geek-goddess-bonnie.blogspot.com
    Tuesday, October 20, 2009 12:12 AM