djjlewis:
The first one that springs to mind is that when child lists and items are are created there is a call directly to DataPortal.CreateChild<ChildType>(parms...) rather than calling a LineItems.GetLineItems() factory metho and then the factory method of LineItems doing the call to DataPortal.CreateChild. This is also the case when LineItems adds in a specific line item it would directly call DataPortal.CreateChild<LineItem>(). I can see that it eliminates an extra call but just wondered if this is now the "preferred" approach or whether or not one way should favoured over another?
Well they are just demo apps, that's true. But I wrote them using the style of coding that I've been using lately.
The super-consistent factory model used in ProjectTracker was primarily in response to comments from the previous book where there was confusion around the different implementations between parent and child types. I wanted to clearly illustrate that version 3.5+ allows complete structural parity between parent and child types.
But in practice I confess that I usually don't implement the internal factory methods on child types, preferring instead to directly use the child data portal functionality.
I appreciate that these are just demo appa so I'm probably reading too much into this, but another thing I noticed is that none of the collection classes implement a default private constructor - was there a specific reason for this or just ignored as it's a demo app ;-)
That's an oversight on my part... I keep switching between .NET and SL. In SL you can't have private default constructors, and technically they aren't required in .NET either. The value of having a non-public default ctor in .NET is to remind developers to use the factory methods. But in SL developers don't (can't) have that crutch, and I suppose I'm slowly falling out of the habit of declaring the ctor at all in most cases...
CSLA doesn't really care - as long as you have a default ctor it doesn't matter what scope it is (except on SL where it must be public).
Can I also just confirm that the best approach for dealing with managed properties is to always read class properties directly but wrapped inside a BypassPropertyChecks (so long as they are not needed) rather than calling ReadProperty, and that read-only properties are implemented by using a private setter that calls LoadProperty rather than using LoadProperty at various places within a class (thus eliminating calls to ReadProperty on the whole and greatly reducing the number of calls you would make to both LoadProperty)
When I wrote the 2008 book the BypassPropertyChecks concept was introduced quite late in the process. Rather than risking tons of errata in the book, I didn't use it to speak of (or at all?) because I was so far into the book at the time - and ProjectTracker is the demo for the book, not necessarily the demo for CSLA .NET in general - so the most important thing is that ProjectTracker match the book.
But let's face it, the code is a lot easier to read if you use BypassPropertyChecks, and if your read-only properties have a private setter that calls LoadProperty().
I think it is safe to say that the 4.0 snippets for a read-only property will conform to that model :)
Copyright (c) Marimer LLC