none
DataSet re-design RRS feed

  • Question

  • Is there any plan for Microsoft to re-engineer the Strongly Typed DataSet to use Generics rather than poor performant Object type casting which occurs underneath its covers?

    For example, here is sample code from a Strongly Typed class generated by Visual Studio.

    /// <summary>
    ///Represents strongly named DataRow class.
    ///</summary>
    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Design.TypedDataSetGenerator", "2.0.0.0")]
    public partial class PropEquiRow : global::System.Data.DataRow {

       private PropEquiDataTable tablePropEqui;
      
       [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
       internal PropEquiRow(global::System.Data.DataRowBuilder rb) : base(rb) {
          this.tablePropEqui = ((PropEquiDataTable)(this.Table));                                 //Casting of generic Table object to Strongly Typed Table object
       }
      
       [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
       public string DOCUMENTCODE {
          get {
             return ((string)(this[this.tablePropEqui.DOCUMENTCODEColumn]));        //Casting of generic Column object to Strongly Typed Column object
          }
          set {
             this[this.tablePropEqui.DOCUMENTCODEColumn] = value;
          }
        }
        ...
    }


    Objects - first class citizens: identity, public interfaces and authority over behaviour and state
    Monday, January 4, 2010 3:26 PM

Answers

All replies

  • Hello,

     

    Welcome to ADO.NET DataSet forum!

     

    I agree that using generic types can be a good option.  However, all the strongly typed DataTable, DataRow and DataColumn all inherit the base types DataTable, DataRow and DataColumn.  We can create a generic table outside, but we still need to cast the tables, rows and columns from base type to derived type internally.  

     

    Would you mind providing us with some samples of a generic strongly typed DataSet that you mean?  Do we need to redesign the whole DataTable and DataSet classes in ADO.NET 2.0?  

     

    Thank you so much!

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    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.
    Tuesday, January 5, 2010 5:32 AM
    Moderator
  • Hello,

     

    I am writing to check the status of the issue on your side.  Could you please provide us with more detailed information? 

     

    If you need further assistance, please feel free to let me know.   I will be more than happy to be of assistance.

     

    Have a nice day!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    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.
    Thursday, January 7, 2010 4:05 AM
    Moderator
  • Thanks for your inquiry.  Sorry, about not responding earlier as I have been distracted elsewhere.
    I guess my question stems from my view of DataSet is that it is first and foremost a data container and as such should be very amenable to being implemented internally using generics ie. List<int> or List<MyTables> or List<MyTableRelations> or List<MyTableConstraints> etc.  Of course after that it also provides a host of other services.  Currently my understanding is that if if you have a typed dataset it is constrained by the fact that it inherits from DataSet which is designed using the common Java programming pattern which uses the general object type.  Because of this, it requires additional introspection/casting to appropriate types.  Therefore, the Strongly Typed DataSet is really just a wrapper that is still confined by the underlying DataSet base class implementation.  Yes, the user sees a proper typed object but underneath it is still using the old paradigm which is impacting its overall performance.
    Please advise if I'm missing something in my assumptions.

    Best Regards,

    Objects - first class citizens: identity, public interfaces and authority over behaviour and state
    Friday, January 22, 2010 6:06 PM
  • Note, if DataSet was defined by Interfaces, a Typed DataSet could simply implement the behaviour rather than rely on inheritance - a rewrite of DataSet may be somewhat of a major architectural challenge.  If DataSet is not defined by required interfaces, then you may have to define basic TypedDataSet behaviour and create a TypedDataSet2 implementation that also includes all other required interfaces (databinding, etc.) with possible assignment conversion ability between old and new.
    Objects - first class citizens: identity, public interfaces and authority over behaviour and state
    Friday, January 22, 2010 7:25 PM
  • Hello,

     

    Thank you very much for your suggestions!   As I said in my first post, I agree with you that using a generic types is really a good idea.  However, the ADO.NET DataSet is a great pattern for disconnected data from the database.   The regular DataSet can be used in any data structures, which is very flexible.  If we create a generic interface for all the DataSet, I think first we need to implement the interface for regular DataSet, like:

    ============================================================================================================

    interface IDataSet<T> { }

    class MyDataSet : IDataSet<DataTable> { }

    ============================================================================================================

    However, the current DataSet class is very powerful.  If we let the strong typed DataSet implements the interface instead of inheriting the current DataSet, we cannot use the powerful functionalities of the current DataSet class.  Defining a basic TypedDataSet could be a good option as you suggested.  In my opinion, to redesign the whole DataSet can cause lots of problems because many applications need to be modified.   The trend of the ADO.NET seems to be the Entity Framework which is more object-oriented designed.   Do you think so?   J  

     

    Have a nice day!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    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, January 25, 2010 8:23 AM
    Moderator
  • I totally understand the issues related to legacy code and how much inertia they have...  Mountains of legacy code are everywhere.

    In the end, a DataSet based on an object is a good general data container, but a DataSet based on Generics is a better implementation of a container that is more effective and efficient.  Build this right and you can dove in the backward compatibility with additional operators if need be.

    You probably shouldn't have spoke of the trend towards Entity Framework as below is going to be a rant which provides an alternate view of today's current direction.

    I disagree with the current trend/thinking of lets create NHibernate and call it Entity Framework for MS.  OO Design to me is all about defining things as close to reality (the domain) as they need be for their intended purpose.  By keeping to this design, you only model what you need and you add value through specificity.  Some may argue that OO design means model everything as an Object.  To me this hasn't added any value - everything is an object.

    I've seen arguments made that you could model every type as a string - Why not?  A string serializes well.  How about a hashtable of hashtables - very flexible design (I say this facetiously).  In the end, everything is just a series of bytes isn't it?  If you simply want a Heap of stuff it is, but generally some greater order and structure is required to when building something of value.  Order and structure are implied in design.  The ability to classify and define specialization flex points is the Real Value good analysts, architects and developers bring to the table.

    We talk of Generics in .NET as though it was some new thing, when it is really a form of or an idea taken from proven C++ style templates and modified for the .NET Framework.  Why did it take so long to become part of .NET?  Because it was either too complicated or it was simply not Java?   (Note I was a certified Java developer for 2.0 for a number of years before I was a .NET developer).  Generics are good!  I would state the reason why is simply because they define something more than just an object and the benefits of this added value impact many areas.

    The most flexible designs that I've seen and implemented are ones where they are built with the purpose in mind (design by interface) and usually involve a strategy or some sort of protocol for use.  The objects are modeled at various levels of abstraction from interface definitions, to abstract classes, to very specific implementations.  To do this takes experience and it often comes through multiple attempts at implementation that are not so good.

    To me, I am looking for a Data Centric Data Container that simply maps efficiently and effectively one-to-one with my Database (a proven and scientific normalized relational data model).  Wow, I see drag and drop ability here without huge thought about implementing a data layer (obviously there is a pick and choose option as currently available for tables and columns).  This is the DataSet!  I simply want it to work better by implementing Generics.  With the DataSet I can focus on implementing my business rules, features and transforming data contexts as required.  At this point I seem to be bucking the trend.  As an application developer, I see myself creating any number of views of the data as needed to fill out my feature set.  Note, I do not consider there to be an impedance mismatch between the database and the object model, which seems to be the latest buzz word.  For example, in most databases, many Views exist - (there are typically more views than tables) and you don't go talking like it’s a dirty thing to have them.  Instead you view the data as simply needing to serve many purposes.  Is there an impedance mismatch, if there is it also exists within the application layer itself whenever you create a fly-weight model or do a shallow copy vs. a deep copy or create any sort of DTO.  What are your interfaces messages like?  Do they send entire object references, small discreet items or a combination of both?  What if it’s a Web application?  Is the customer the same on the client as the server?  I think not.
    The term impedance mismatch should be used when it needs to mean something important like the data modeled fails to describe the Business and no longer facilitates its growth.  Everything else is simply ETL (Extract Transform Load).

    Mistakes in Data Modeling occur when the Database Design is driven by the technology being implemented (this is what works best/easiest to implement with NHibernate or some other technology) as apposed to business domain or by short sightedness within the abstraction layer which is typical of junior coders eager to get coding rather than relying on domain experts.  The thought of an application willy nilly writing DDL dynamically to the database is an abomination.  Implementation issues are not about how fast DDL can be written, implementation is dictated more by how fast rational decisions can be made and should be based on acquired knowledge and analysis of dependencies with efforts coordinated between other users and parties of interest. 

    Reality is there are trade-offs for the time/cost investment in design and it raises the question is there any value in taking extra time to produce something well?  I would refer you to ponder our domestic car manufacturer’s plight vs. the high end import manufacturers.  There product sells for more and yet their market share is increasing.  Knowledgeable customers perceive quality and are willing to pay for it, rather than pay for something that is broken over and over and over again.  In the trenches dealing with legacy business culture, code, and limited skill sets requires an art for balancing the attainable based upon the time and tools at hand to ensure projects are delivered.

    Good data modeling really doesn't require rocket science just basic data modeling 101 with a desire to analyze and understand the business being modeled- not just some developer's hack at modeling which may suggest "because its possible in XML and because XML is the most flexible we should implement it in XML".  XML is great as an Import/Export format, but internally use formally defined structures/conventions.  I might sound rigid, maybe, but I've seen a number of business data models that have cost those businesses a great deal of money in failed projects or systems which have prevented the business from adapting to changes or provided a much lower level of service to both external and internal clients than would have been possible otherwise.  Data modeling takes skill, which many of today's developers don't appear to have learned.  My mantra is "the data model is the foundation for your enterprise's intellectual property" - you might build a good application upon a good data model, but you can only compromise on your solution with a poor data model and until it is fixed it will continue to be very costly to maintain and service down the road.

    I also do not believe an application or application developers own the data.  In business applications, the business owns the data.  Application developers come and go and many applications are built and rebuilt around the data of an enterprise.  The data is central and it lives as long as the enterprise and then sometimes longer.  If it is modeled wrong, everyone will know it as it permeates outwards to ends unknown...


    Objects - first class citizens: identity, public interfaces and authority over behaviour and state
    Wednesday, January 27, 2010 3:52 AM
  • Hello,


    Great!  Thank you so much for your posting!!!   Very reasonable and full of knowledge.  I strongly recommend you send your suggestion on the DataSet at Microsoft Connect.  I think your idea is really helpful for both the product team and community members.  If it is convenient, could you please share the connect ticket link here to benefit more community members?   Thanks again!

     

    Have a nice day!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    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.
    Thursday, January 28, 2010 1:24 PM
    Moderator
  • Hello,

     

     

    How are you?   How is it going?  Have you sent a suggestion at Microsoft Connect?   :)


    Hope you have a nice day!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    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, February 1, 2010 12:57 AM
    Moderator
  • Hi,
    I didn't send the suggestion, but I will since you feel its worth doing.
    I would appreciate your advise on What title would you recommend me put it under - DataSet Re-design using Generics?
    In addition, would the first question in this thread be sufficient?
    Thanks for your help.


    Objects - first class citizens: identity, public interfaces and authority over behaviour and state
    Tuesday, February 2, 2010 10:40 PM
  • Hi,

     

    Thank you very much for following up on this case.  

     

    Yes, I agree that the title “DataSet re-design using Generics” is great!   Besides, I think you can provide some information in the Connection suggestion ticket and give this thread to the product team as well.   Great suggestions like yours are always welcome for Microsoft. 

     

    If you have any questions, please feel free to tell me. 

     

    Hope you have a great day!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    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.
    Wednesday, February 3, 2010 8:03 AM
    Moderator
  • I have posted the suggestion up on the Connection site under the title "DataSet re-design using Generics".
    Here is the link: https://connect.microsoft.com/VisualStudio/feedback/details/530872/dataset-re-design-using-generics#details
    Thanks for your encouragement and may your day be full of Peace and Joy.

    Objects - first class citizens: identity, public interfaces and authority over behaviour and state
    Thursday, February 4, 2010 5:02 PM
  • Hi,

     

    Great!  Thank you so much for sharing the link here!   I learnt much from you indeed.   

     

    Hope you have a nice weekend!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    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.
    Saturday, February 6, 2010 8:32 AM
    Moderator