POCO Data Transfer Objects

[kobi-shanti]

We're in the midst of migrating an existing CSLA4 app to CSLA5 and at the same time move to a 3-tier architecture.

We've found that fetching lists of BusinessBase objects was slower and resulted in larger payloads than if we used DataSets and populated our business objects from these as required. The issue we're facing now is that CSLA does not want to serialize/deserialize DataSets in 3-tier.

As an alternative, we're investigating the use of lighter POCO DTOs to get data across the data portal. We've come across the MobileObject class and are interested in using it instead of BusinessBase as it doesn't appear to come with all the extra toppings. We have attempted to implement a DTO that inherits from MobileObject, but the DTO never contains the data once it gets back to the client side of the data portal. Based on some posts here https://github.com/MarimerLLC/cslaforum/issues/909 and here https://github.com/MarimerLLC/csla/issues/2148 we've tried to implement GetState and SetState but these have not resolved the issue. Are there more requirements for using MobileObject? Here's an example of the POCO DTO

[Serializable]
public class DTO : MobileObject
{
    public MobileList<string> ColumnNames { get; set; }
    public MobileList<string> ColumnTypes { get; set; }
    public MobileList<MobileList<object>> Rows { get; set; }

    public DTO()
    {
        ColumnNames = new MobileList<string>();
        ColumnTypes = new MobileList<string>();
        Rows = new MobileList<MobileList<object>>();
    }

    public void GetState(Csla.Serialization.Mobile.SerializationInfo info)
    {
        info.AddValue("ColumnNames", ColumnNames);
        info.AddValue("ColumnTypes", ColumnTypes);
        info.AddValue("Rows", Rows);
    }

    public void SetState(Csla.Serialization.Mobile.SerializationInfo info)
    {
        ColumnNames = info.GetValue<MobileList<string>>("ColumnNames");
        ColumnTypes = info.GetValue<MobileList<string>>("ColumnTypes");
        Rows = info.GetValue<MobileList<MobileList<object>>>("Rows");
    }
}

[kobi-shanti]

My apologies for the somewhat premature post. I managed to get this working by overriding OnSetState and OnGetState. Here's the working example:

[Serializable()]
public class DTODataTable : MobileObject
{
    public MobileList<string> ColumnNames { get; set; }
    public MobileList<string> ColumnTypes { get; set; }
    public MobileList<MobileList<object>> Rows { get; set; }

    public DTODataTable()
    {
        ColumnNames = new MobileList<string>();
        ColumnTypes = new MobileList<string>();
        Rows = new MobileList<MobileList<object>>();
    }

    protected override void OnGetState(Csla.Serialization.Mobile.SerializationInfo info, StateMode mode)
    {
        info.AddValue("ColumnNames", ColumnNames);
        info.AddValue("ColumnTypes", ColumnTypes);
        info.AddValue("Rows", Rows);
    }

    protected override void OnSetState(Csla.Serialization.Mobile.SerializationInfo info, StateMode mode)
    {
        ColumnNames = info.GetValue<MobileList<string>>("ColumnNames");
        ColumnTypes = info.GetValue<MobileList<string>>("ColumnTypes");
        Rows = info.GetValue<MobileList<MobileList<object>>>("Rows");
    }
}

[rockfordlhotka]

I am curious as to why you are flowing DTOs through the data portal?

Normally a DTO exists purely within the Data Access Layer to provide a neutral abstraction so you can swap out different types of data access frameworks without impacting the object-data mapping to get the data into your business domain objects.

In a typical CSLA app, the Interface and Interface Control layers interact purely with business domain types, not dumb data containers like a DTO.

[kobi-shanti]

First of all I want to say I am no expert in CSLA or anything else for that matter. Secondly, our app is probably not typical or standard in that it doesn't strictly follow the CSLA approach.

The reason we're experimenting with the DTO (maybe not the best description) is speed/performance. We've found that when we use a list of BusinessBase objects or the BusinessBindingListBase object and run a Fetch to get data for multiple instances from the DB, that we end up with a lot of repeated information in the payload going through the data portal. From what I understand, this seems to just be the nature of serializing a list of objects - you end up with repeated "header/definition" information for each object along with it's data.

As a workaround, we've previously used DataSets to get data through the data portal. We then populate our BusinessBase/BusinessBindingListBase objects with this data on the client side. The approach with DataSets resulted in serialized payloads that were less verbose and had better performance when it came to time.

Now when we went to use 3-tier with CSLA5, we couldn't get our approach to work with DataSets as the mobile formatter didn't want to serialize them. The "DTO" acts as a slimmer version of the DataSet that can be serialized by the mobile formatter. We're currently populating the DTO with raw data on server side of the data portal and then transferring it through to the client. Once on the client side, we populate our BusinessBase objects from the data in the DTO. Even with the conversion from DataSet to DTO, and then DTO to BusinessBase, we're getting better performance. A test we ran compared the time to bring back ~4400 objects using Fetch vs DTO. The DTO approach took less than half the time.

Our intention with the move to CSLA5 and 3-tier was to get our code base closer to the template code for CSLA, but we (and our clients) can't accept a massive performance hit by doing so.

Is there a better choice than a list of BusinessBase objects or the BusinessBindingListBase object for getting data for multiple objects of the same type through the data portal (keeping in mind we need the objects to be editable on the client side)?

[hurcane]

When you say that you have repeated header/definition data, I interpret that as meaning you have a parent/child relationship, such as an order with lines. Without understanding your full business environment, I cannot make a specific recommendation.

However, I am highly sensitive to data performance. One of our core edit use cases is a bill of materials which supports unlimited nesting of components. Each component has multiple child properties. Users load a single BOM with over 10000 unique components in just a few seconds using a three-tier model (Winforms / IIS / SQL Server). The business object is fully instantiated with one call to the IIS process.

You should be able to encapsulate header data in a single instance and not have that information duplicated when the business object is setialized. We use a variety of techniques to avoid duplication in scenarios where header data needs to be shared with the children. With more context, I might be able to share some specific patterns.

If your data isn't editable, the read-only classes are more lightweight.

[Chicagoan2016]

@hurcane , I don't want to hijack this thread : ) but I am really interested in the use case you described.
Yesterday I was asked to change the layout of a form with multiple tab pages (Winforms) to a form with no tabs, resulting in a very 'long' form (users like it lol).
This will result in multiple objects getting their data from the Database during a fetch operation and some of these objects have in turn child objects. Since the tabs are gone, I can't call 'Fetch' on demand.
Would love to hear your thoughts.
I could start another thread.

Kind Regards

[kobi-shanti]

Hey thanks for the response.

To try to add a bit more context, we're using a very similar three-tier model (Winforms / IIS / SQL Server). I'm not talking about parent/child relationships, instead I'm referring lists of the same object (E.g. a list of Orders).

When we've inspected the data going across the network for a list of objects via a Fetch, we noticed repeated object definition data for each instance in the list. For every object instance, each property name is repeated along with the property's value.

With the approach of the DTO above, instead of repeating the property names for every instance in the list we're just repeating indexes. The difference between indexes and full property names saves a fair bit of size in the resulting payload. The difference adds up when dealing with a large number of instances or objects with many properties.

The CSLA fetch approach does appear to be better (smaller payload) when returning a single instance of an object, as the DTO object has unnecessary properties that take up space in the resulting payload.

I don't believe read-only list classes are an option as we allow editing of data in grids.

[swegele]

I remember many years ago that Rocky mentioned that he used a different pattern for huge Bulk/Batch data scenarios (forgive me I don't remember the context of his comment). I had it in the back of my mind until a couple years ago...a certain large nationwide government agency had a requirement to perform 10,000 very complex operations that included SQL db transaction in 10 seconds or less. The actual number of db operations (from sub-operations) ended up being > 100,000.

One of the ways I increased perf was to have a "parent helper" class that abstracted the details away from the developer of a massive number of children kept in a simple data container stored privately. I made the container inside the CSLA object as simple as possible (basically a list of tuples with string properties). Using simple lists of strings instead of the more complex readonly BO drastically increased the speed.

The second way I used to increase speed was to use ADO SQLBulkCopy to send that data to SQL server via dataset to be processed on db server.

This was a nice hybrid "special pattern" for that specific bulk scenario. For 98% of our LOB app, the standard doctrinaire approach to CSLA works very fast and the code is quite simple. So my approach (right or wrong) is to go standard until a use case presents itself that requires special treatment.

HTH in your efforts to design something that works for you.

[rockfordlhotka]

I think you might be referring to the Unit of Work pattern? Where a root object is responsible for orchestrating some potentially large set of related server-side operations?