Advantages of Typed DataSets

From OpenPetra Wiki
Revision as of 08:46, 2 August 2011 by Christiankatict (talk | contribs) (Created page with '==Overview== OpenPetra's Typed DataSets are the main means by which we transfer data between PetraServer and PetraClient (and…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Overview

OpenPetra's Typed DataSets are the main means by which we transfer data between PetraServer and PetraClient (and vice versa). They provide many advantages over the standard .NET DataSets.

The resulting source code that defines the resulting Typed DataSets is automatically created by a generator (invoked by 'nant generateORM').


List of Advantages of Typed DataSets

  • Server side / Client side advantages
    • Typed DataTables instead of everything just being of Type DataTable.
      • Relieves the developer from casting all the time. Casting is annoying for the developer and error-prone, and one only finds out at run-time whether the cast to a certain Typed DataTable is correct as one side of the cast is always of Type DataTable and therefore will accept any DataTable (and any Class that inherited from it, which all Typed DataTables do) at compile-time.
      • Provides compile-time checks for the correct Type when accessing the Typed DataTables.
    • Easier referencing of DataTables: MyDataSet.MyTable instead of MyDataSet.Tables['MyTable']
      • When using the MyDataSet.MyTable notation: The IDE offers Code Completion and shows ToolTips about the Type of the Typed DataTable when the mouse cursor is 'hovering' over a DataTable name.
      • When using the MyDataSet.MyTable notation: Performance increase - the lookup of the index of the DataTable is done only once, whereas with a normal DataSet it is done everytime a DataTable is accessed by name.
    • Typed DataSets already contain Schema information. This makes loading of data faster and less CPU-intensive because the Schema doesn't need to be retrieved from the DB and doesn't need to be built on the fly - everytime data is loaded into a new instance of a DataTable!
    • Typed DataSets already contain Constraints. These are available at runtime on the Server-side as well as on the Client-side (without any accessing of the DB)!
      • The Constraints are automatically generated from the \db\petra.xml file
      • It is also possible to add custom Constraints and DataRelations in the XML files that specify the Typed DataSets. This means that we don't need to program them!
    • Special functionality can be built in (such as a function that optimises the amount of data that is sent via .NET Remoting).


Performance and Memory Footprint, .NET Remoting Data Transfer

  • Performance / memory footprint vs. normal DataSets (small / large amount of data)
    • Memory consumption and CPU utilisation server side
      • Loading data from Server to Client
        • Using Typed DataSets the memory consumption is negligibly higher, and the CPU utilisation 8% to 16% less!
          • Example: PartnerEditUIConnector Typed Dataset (Tables: Partner, PartnerType, PartnerSubscription, Person, PartnerLocation, Location):
            • 4 Addresses, 5 Subscriptions (PartnerKey 29024605): Additional memory consumption: approx. 2.000 Bytes, CPU utilisation: -10%
            • 1 Address, no Subscriptions (PartnerKey 29068283): Additional memory consumption: from not measurable to approx. 1.000 Bytes, CPU utilisation: -8% to -16%
    • Memory consumption and CPU utilisation client side
      • Loading data from Server to Client
        • Using Typed DataSets the memory consumption is negligibly lesser, and the CPU utilisation 8% to 12% less!
          • Example: PartnerEditUIConnector Typed Dataset (Tables: Partner, PartnerType, PartnerSubscription, Person, PartnerLocation, Location):
            • 4 Addresses, 5 Subscriptions (PartnerKey 29024605): Lesser memory consumption: approx. 300 Bytes, CPU utilisation: -10%
            • 1 Address, no Subscriptions (PartnerKey 29068283): Lesser memory consumption: approx. 350 Bytes, CPU utilisation: -12%
  • .NET Remoting data transfer vs. normal DataSets
    • per transferred Typed DataTable approx. 253 - 630 Bytes are transferred additionally compared with a normal (untyped) DataTable
    • Example: PartnerEditUIConnector's Typed Dataset 'PartnerEditTDS' (Tables: Partner, PartnerType, PartnerSubscription, Person, PartnerLocation, Location):
      • 4 Addresses, 5 Subscriptions (PartnerKey 29024605): Additional data transfer: 3.784 Bytes (31.715 Bytes vs. 27.931 Bytes)
      • 1 Address, no Subscriptions (PartnerKey 29068283): Additional data transfer: 1.571 Bytes (23.858 Bytes vs. 22.287 Bytes)