CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • Slowly Inching to Csla4.0. Question about the final step

    rated by 0 users
    Answered (Verified) This post has 1 verified answer | 7 Replies | 2 Followers

    Top 25 Contributor
    397 Posts
    Jav posted on Mon, Jul 19 2010 12:56 PM

    From VS2008, SL3.0, .Net3.5 and Csla3.8.4, I have arrived at VS2010, SL4.0, .Net4.0 and Csla3.8.4

    So far so good.  The App runs fine in my development server.  I have downloaded Csla4.0 and "installed" it.

    I know about the issue of changing PropertyInto stuff from Private to Public, which I am starting on rigt now.  My Validation Rules have not been set up yet, nor authorization rules - I wanted to get to 4.0 before starting on those.

    Is there any other preparatory change I need to make before "crossing over"?

    Jav

    Answered (Verified) Verified Answer

    Top 10 Contributor
    9,475 Posts

    I think the big things when moving from 3.8 to 4 include:

    1. Understanding the new CSLA assemblies (Csla,dll, Csla.Web.dll, Csla.Xaml.dll, etc)
    2. If doing Silverlight 4, making the PropertyInfo<T> fields public
    3. Changing business rules to the new model
    4. Changing authorization rules to the new model
    5. Updating any use of LINQ to CSLA for the new implementation
    6. Switch from non-generic data portal to generic data portal (if necessary)

    Then there are the things you can choose to exploit:

    1. New MVVM support in Silverlight/WPF
    2. New ASP.NET MVC support
    3. Support for SL 4 data binding UI features
    4. Simplified criteria passing
    5. Simplified data portal configuration
    6. and more...

     

     

    Rocky

    All Replies

    Top 10 Contributor
    9,475 Posts

    I think the big things when moving from 3.8 to 4 include:

    1. Understanding the new CSLA assemblies (Csla,dll, Csla.Web.dll, Csla.Xaml.dll, etc)
    2. If doing Silverlight 4, making the PropertyInfo<T> fields public
    3. Changing business rules to the new model
    4. Changing authorization rules to the new model
    5. Updating any use of LINQ to CSLA for the new implementation
    6. Switch from non-generic data portal to generic data portal (if necessary)

    Then there are the things you can choose to exploit:

    1. New MVVM support in Silverlight/WPF
    2. New ASP.NET MVC support
    3. Support for SL 4 data binding UI features
    4. Simplified criteria passing
    5. Simplified data portal configuration
    6. and more...

     

     

    Rocky

    Top 25 Contributor
    397 Posts
    Jav replied on Mon, Jul 19 2010 3:42 PM

    Thank you.  That would be very helpful.

    One interesting observation (for all I know it may be expected)

    While still working with Csla 3.8.4, I changed all PropertyInfo declarations from private to public. To Create my Root object, I need to send 4 parameters, which I do with an old style Criteria class, which is implemented as shown below.  The observation was that when the PropertyInfo items within the Criteria class were changed from private to public, it generated a runtime error as shown below.

    Here is my Root object factory method:
           public static void NewEncounter(Int32 personKey, Int32 param2, Int32 param3, Int32 param4,                                                                                      EventHandler<DataPortalResult<Encounter>> callback)
            {
                var dp = new DataPortal<Encounter>();
                dp.CreateCompleted += callback;
                dp.BeginCreate(new Encounter.Criteria(personKey, param2, param3, param4));
            }

    Here is the Criteria Class:
            [Serializable()]
            class Criteria : Csla.CriteriaBase
            {
                public static PropertyInfo<Int32> PersonKeyProperty = RegisterProperty<Int32>(typeof(Criteria), new PropertyInfo<Int32> ("PersonKey","PersonKey"));
                public Int32 PersonKey
                {
                    get { return ReadProperty(PersonKeyProperty); }
                    set { LoadProperty(PersonKeyProperty, value); }
                }

                ...........  Other Properties ..........................

                public Criteria(Int32 personKey, Int32 argument2, Int32 argument3, Int32 argument4)
                {
                    this.PersonKey = personKey;
     ..................   other criteria arguments ..................
                }
           }


    ---------------------------
    Data error
    ---------------------------
    Csla.Reflection.CallMethodException: NewEncounter method call failed ---> Csla.PropertyLoadException: Property load or set failed for property PersonKey (Attempt by method 'Csla.Core.FieldManager.FieldDataManager.ForceStaticFieldInit(System.Type)' to access field 'VisitLibrary.Encounter+Criteria.PersonKeyProperty' failed.)
    at Csla.Core.ManagedObjectBase.LoadProperty[P](PropertyInfo`1 propertyInfo, P newValue)
    at VisitLibrary.Encounter.Criteria.set_PersonKey(Int32 value)
    at VisitLibrary.Encounter.Criteria..ctor(Int32 personKey, Int32 param2, Int32 param3, Int32 param4)
    at VisitLibrary.Encounter.NewEncounter(Int32 personKey, Int32 param2, Int32 param3, Int32 param4, EventHandler`1 callback)
     --- End of inner exception stack trace ---
    at Csla.Reflection.MethodCaller.CallFactoryMethod(Type objectType, String method, Object[] parameters)at Csla.Silverlight.ViewModelBase`1.BeginRefresh(String factoryMethod, Object[] factoryParameters)

    Jav

    Top 10 Contributor
    9,475 Posts

    Your RegisterProperty() call isn't using the lambda syntax, and your first parameter (the typeof() parameter) is incorrect.

    Rocky

    Top 25 Contributor
    397 Posts
    Jav replied on Tue, Jul 20 2010 3:48 PM

    Aah!

    That was the first and only multi-argument Criteria class I wrote almost 8 months, don't even know where I got that code.  Amazingly it's been working all these months.

    In VS2010, I am using:
            private class Criteria : Csla.BusinessBase<Criteria>

    In VS2008 I have already tried:
            private class Criteria : Csla.BusinessBase<Criteria>, ICriteria
    and it appears to work fine

    I have now also learnt that in Csla4, ICriteria is neither available nor necessary.

    Jav

    Not Ranked
    2 Posts

    I need a second pair of eyes on this...

    I am using RegisterProperty with the Lambda syntax (see my example below), I also have the PropertyInfo set as a public static instance, however; I am getting the exact same error he is describing in his original question.  The exception is thrown in my code by CSLA when I call LoadProperty with the value to set (I am just setting it inside my constructor as shown below).  FWIW - this is on a SilverLight application happening on the client side.

    I must be missing something somewhere because I am using the built in Csla.Security.UsernameCriteria class in my own custom identity implementation and LoadProperty works fine in there...

    [Serializable]
    private class CustomerCriteria : CriteriaBase<CustomerCriteria>
    {
             public static PropertyInfo<Guid> CustomerIdProperty = RegisterProperty<Guid>(p => p.CustomerId);

             internal CustomerCriteria(Guid custId)
             {
                    CustomerId = custId;
             }

             public Guid CustomerId
             {
                   get { return ReadProperty(CustomerIdProperty);
                   private set { LoadProperty(CustomerIdProperty, value); }
             }
    }

     

    Not Ranked
    2 Posts

    Spent some time poking around the CSLA codebase to see if I could figure out what I was doing wrong in my code...

    Interesting - the problem seems to be that I cannot have a private nested criteria class in my business object, and I need a public parameterless constructor on the Silverlight side as well - once I made the criteria class public and added the constructor was able to call LoadProperty without issue.

    It would seem that I am going to have to unlearn some habits I got used to doing in the earlier versions of Csla...

    Top 10 Contributor
    9,475 Posts

    The Silverlight runtime imposes some limitations on what can be done, and CSLA had to be altered to accommodate them.

    The "Using CSLA 4" ebook series, and the Silverlight video series touch on most of the difference points.

    The upside to adapting though, is that WinRT imposes similar limitations (I think of it as basically being Silverlight 6 :) ), so if you get used to programming for Silverlight you should be all set for WinRT.

    Rocky

    Page 1 of 1 (8 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems