RoleList (NVL) in ProjectTracker.Library - question

RoleList (NVL) in ProjectTracker.Library - question

Old forum URL:

TSF posted on Friday, October 28, 2011

I know NVLs aren't used as much anymore, but I'm still trying to understand this:  in the ProjectTracker example provided with the new WPF/SL e-book, there doesn't seem to be a public constructor defined for the RoleList class.  In addition, the SL code provides a sync GetList method that returns a RoleList.  If the cached list is available, it returns that.  If it isn't available, it returns "new RoleList()".  What gets returned in the latter case?  An empty list?  If so, why wouldn't it call the async GetList method to get the actual data?  Here's what I'm referring to:

public static RoleList GetList()
  if (_list != null)
    return _list;
    return new RoleList();

RockfordLhotka replied on Saturday, October 29, 2011

There is no constructor defined at all, so the compiler does the normal thing and creates a public default constructor. That's standard .NET/SL behavior.

The GetList factory on SL is interesting. Ideally it shouldn't even exist as a synchronous method, but I chose to rely on some side-effect behavior to avoid having async complexity spread throughout the code.

If you look through the code, you'll find that the sync GetList is only used by the RoleName properties in classes like ResourceAssignmentEdit.

I could have made that async, but really, the idea is that in an SL/WP7 app a unit of work will have been used to get the various root objects - thus ensuring that RoleList is loaded into memory before any root objects are bound to the UI.

It is a balancing act. Do you allow/force async behaviors to flow through large parts of the app? Or do you make assumptions about proper use of UOW objects and allow some of the code to use simpler sync implementations?

Once we all move to C# 5.0 and VB 11, we can use the async/await keywords (CSLA 4.5 should support this), and that'll help this whole issue go away - because the sync and async code are of comparable complexity. There'll still be a performance difference, so proper use of a UOW is still critical, but at least the code can be async everywhere without becoming complex.

Copyright (c) Marimer LLC