Project Tracker 4.0

Project Tracker 4.0

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


AaronH posted on Tuesday, April 27, 2010

Will Project Tracker 4.0 be updated to properly reflect and use all of the new features that CSLA 4.0 provides?  An SL project included in the solution would also be very helpful to cover new features. 

I just downloaded the 4.0 samples and noticed in one of them that we no longer need to provide public constructors for our SL BO's, which is awesome.  It would be nice to have the full-blown PT project streamlined that takes advantage of the new rules engine, validation, data annotations support, etc.

Thanks for listening!

RockfordLhotka replied on Tuesday, April 27, 2010

SL still requires public default constructors - that's a limitation of the SL reflection model. But in a lot of SL focused samples I don't implement any constructor code at all since the compilers generate a public default constructor if you don't define any explicitly.

There will be updates (eventually) to all the samples, including ProjectTracker. Or I'll replace ProjectTracker with something - I haven't entirely decided. In svn right now the C# ProjectTracker builds, and includes semi-functional Web Forms, MVC and Windows Forms interfaces - all using CSLA 4. It doesn't entirely work, nor is the MVC UI complete, but it is a start on the update.

AaronH replied on Tuesday, April 27, 2010

Interesting, I downloaded the CSLA SL 4.0 Samples and in the SimpleApp.CustomerEdit, ran into the following:

    [Obsolete("For use by MobileFormatter")]
    public CustomerEdit()
    { /* required by MobileFormatter */ }

I guess I assumed that someone had marked the constructor as obsolete in anticipation of a new change coming. 

In any case, either an updated ProjectTracker or new themed application would be really awesome and appreciated by a number of us in the community.

 

 

RockfordLhotka replied on Tuesday, April 27, 2010

No, that's a trick you can use to prevent someone from accidentally using the constructor.

Really you want business objects to always be created through the data portal. The reason for the non-public default ctor in .NET objects is not technical - it is to act as a reminder to people using your business types that they should use the factory methods.

Silverlight requires the public default ctor, so that reminder goes away. Your only hope of ensuring proper coding is to do code reviews (or to get Jason Bock to write an fxcop rule Smile).

Or mark the constructor as obsolete, so anyone trying to use it gets a compiler warning or error.

Copyright (c) Marimer LLC