CSLA 4.3.13 ProjectTracker

CSLA 4.3.13 ProjectTracker

Old forum URL: forums.lhotka.net/forums/t/11698.aspx


ozitraveller posted on Monday, November 12, 2012

Hi 

I'm write a small sample so I can get my head around a later version of csla and hoping some can help me.

So far I have implemented a Dal, DalAdo and Library similar to Tracker. I have also implemented a wrapper for csla MyCsla just in case I wanted to add features later. I have a Winforms UI with a single form with a datagridview on it. The grid loads synchronously, so it works, so far.

Now to my question. I want to be able to load the grid asynchronously and I have implemented methods similar to:

    public static void GetProjectList(EventHandler<DataPortalResult<ProjectList>> callback)

    {

      DataPortal.BeginFetch<ProjectList>(callback);

    }

I problem is that I don't know how to implement the call to GetProjectList from the UI to populate the grid. Calling DisplayList(ProjectList.GetProjectList()); from the UI invokes the synchronous method.

I'm really stuck and been banging my head on this for a while now,  so I'm hoping some can explain what I'm missing.

 

Thanks in advance.

Ozi

 

JonnyBee replied on Tuesday, November 13, 2012

You can send in a parameter of either lambda expression or a method for callback after the async Fetch is completed.

BTW: The "old" style naming convention is to prefix async methods with Begin.
With the new async/await in .NET 4.5 the naming convention is to use Async  as suffix.

With a Callback function:

      Root.BeginFetchRoot(FetchCompleted);
    } 
 
    private void FetchCompleted(object sender, DataPortalResult<Root> e)
    {
       if (e.Error != null)
       {
           // Fetch failed - tell the user 
       }
       else
       {
           // add code to setup databinding 
       }
    }

Or with a lambda callback:
        Root.BeginFetchRoot((o,e) =>         {             if (e.Error != null)             {                 // Fetch failed - tell the user              }             else             {                 // add code to setup databinding                               }         });

ozitraveller replied on Tuesday, November 13, 2012

Thanks JonnyBee that's excellent, and appreciate your time in answering my question.

ozitraveller replied on Tuesday, November 13, 2012

I'd also like to added a feature to return a dataset/datatable for reporting and search screens and thought that using the  a class derived from CommandBase for the purpose. I thought I would populate a hashtable or dictionary from the fields in a special criteria user control for reporting and searching.

Is there a better way to go that someone might have?

Ozi

 

RockfordLhotka replied on Tuesday, November 13, 2012

You can return a DataTable because they are serializable. You should be aware that the DataSet/DataTable don't exist on any modern platforms (Silverlight, Windows Phone, Windows 8 WinRT). As a result, using the DataTable or related types on a client workstation is generally a very bad idea because it will prevent you from upgrading to modern client platforms.

ozitraveller replied on Tuesday, November 13, 2012

Hi Rocky

Thanks for the heads up, but for the time being I'm only using winforms. But now you've peaked my curiosity, how would I convert an app, that uses datatables, from winforms to one of those modern platforms?

 

Cheers

Ozi

RockfordLhotka replied on Tuesday, November 13, 2012

My recommendation is that you follow the guidance in my books and build your UI based on top of a well designed set of business objects derived from the CSLA .NET base classes.

We've put a lot of work into making sure your business classes support data binding on all UI technologies from Windows Forms to WinRT. And to making it reasonable to think that (with little or no code changes) you can just recompile your business code for the various Microsoft platforms (.NET, Silverlight, WinRT, WinPRT) and have the code continue to work as expected.

Microsoft effectively abandoned the DataSet several years ago (2007 or so) when they didn't port it to Silverlight, and then didn't port it to the phone, and stopped building any new tools on or around that technology, instead switching everything to EF. So the deprecation of the DataSet isn't a new phenomenon. And correspondingly, one of the major benefits of using CSLA .NET to build your business layer is that CSLA .NET helps shield you (to some degree) from this type of change in Microsoft's data access strategy over time.

ozitraveller replied on Wednesday, November 14, 2012

Hi Ricky

Thank you for the explanation, and for reminding me why I decided to go with CLSA.Net in the first place and why I continue to use and promote it today.

Cheers

Ozi

Copyright (c) Marimer LLC